Velocity
  1. Velocity
  2. VELOCITY-730

Property references don't work with maps that implement Map indirectly (such as Google Collections ImmutableMap)

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.6.1
    • Fix Version/s: 1.7
    • Component/s: Engine
    • Labels:
      None

      Description

      If you pass a map created using Google Collections ImmutableMap into a Velocity context, and try to access its values using "map.key" style property syntax, it fails to resolve.

      I believe the problem is in MapGetExecutor:

      http://svn.apache.org/viewvc/velocity/engine/tags/1.6.1/src/java/org/apache/velocity/runtime/parser/node/MapGetExecutor.java?view=co

      Specifically, this code:

      Class [] interfaces = clazz.getInterfaces();
      for (int i = 0 ; i < interfaces.length; i++)
      {
      if (interfaces[i].equals(Map.class))
      {
      ...

      The sneaky thing about ImmutableMap is that ImmutableMap.of(...) doesn't return an instance of ImmutableMap, but one of serveral subclasses optimized for however many items are in the map. These subclasses extend ImmutableMap but do not directly implement Map, so that code above fails to recognize them.

      A simpler and more accurate way to tell whether the class implements Map, either directory or indirectly, is "if (Map.class.isAssignableFrom(clazz))..."

        Activity

        Hide
        Nathan Bubna added a comment -

        Yeah, i can see that this would fail, though it's not because the subclasses don't themselves implement Map, but rather that ImmutableMap and descendants are implementors of ConcurrentMap which is a subinterface of Map. We hit a similar problem in the ClassMap class recently (VELOCITY-689). In this case, i think your solution is probably the best one, as it keeps it simple.

        Thanks for reporting this.

        Show
        Nathan Bubna added a comment - Yeah, i can see that this would fail, though it's not because the subclasses don't themselves implement Map, but rather that ImmutableMap and descendants are implementors of ConcurrentMap which is a subinterface of Map. We hit a similar problem in the ClassMap class recently ( VELOCITY-689 ). In this case, i think your solution is probably the best one, as it keeps it simple. Thanks for reporting this.
        Hide
        Nathan Bubna added a comment -

        I attempted to reproduce this in a test case, but the map.key style worked just fine with a class structure designed to simulate that of ImmutableMap. It worked, because Velocity 1.6+ will always look for a get(key) method if it fails to recognize that the object is a Map. the MapGet/MapSetExecutors are merely optimizations.

        So, while the map-specific executors are, indeed, missing things like ImmutableMap (i did confirm that), they are not the sole cause of your problem. You should still be able to use ImmutableMaps.

        Show
        Nathan Bubna added a comment - I attempted to reproduce this in a test case, but the map.key style worked just fine with a class structure designed to simulate that of ImmutableMap. It worked, because Velocity 1.6+ will always look for a get(key) method if it fails to recognize that the object is a Map. the MapGet/MapSetExecutors are merely optimizations. So, while the map-specific executors are, indeed, missing things like ImmutableMap (i did confirm that), they are not the sole cause of your problem. You should still be able to use ImmutableMaps.
        Hide
        Nathan Bubna added a comment -

        Ok, the flaw that kept MapGet/SetExecutor from handling the map.key syntax when the map class didn't directly implement Map has been resolved.

        Show
        Nathan Bubna added a comment - Ok, the flaw that kept MapGet/SetExecutor from handling the map.key syntax when the map class didn't directly implement Map has been resolved.
        Hide
        Tim Moore added a comment -

        Thanks for the fix, Nathan. I think I see why the fallback "get" handling didn't work: there's a related issue with ClassMap (it doesn't see superinterfaces). I'll file a separate issue.

        Show
        Tim Moore added a comment - Thanks for the fix, Nathan. I think I see why the fallback "get" handling didn't work: there's a related issue with ClassMap (it doesn't see superinterfaces). I'll file a separate issue.
        Hide
        Tim Moore added a comment -

        And of course I didn't notice your previous comment where you already said that and linked to the issue! Thanks again.

        Show
        Tim Moore added a comment - And of course I didn't notice your previous comment where you already said that and linked to the issue! Thanks again.

          People

          • Assignee:
            Unassigned
            Reporter:
            Tim Moore
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development