Velocity
  1. Velocity
  2. VELOCITY-717

Engine throws an NPE using custom macro libs if the IncludeEventHandler returns null

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 1.6.2
    • Fix Version/s: 1.6.x, 1.7
    • Component/s: Engine
    • Labels:
      None
    • Environment:
      Suse Linux

      Description

      The Engine throws an NPE if the IncludeEventHandler returns null.
      (using merge method with a list of macro libs)

      java.lang.NullPointerException
      >> at java.util.Hashtable.get(Hashtable.java:333)
      >> at org.apache.velocity.runtime.VelocimacroManager.getNamespace(VelocimacroManager.java:318)
      >> at org.apache.velocity.runtime.VelocimacroManager.get(VelocimacroManager.java:215)
      >> at org.apache.velocity.runtime.VelocimacroFactory.getVelocimacro(VelocimacroFactory.java:563)
      >> at org.apache.velocity.runtime.RuntimeInstance.getVelocimacro(RuntimeInstance.java:1563)
      >> at org.apache.velocity.runtime.directive.RuntimeMacro.render(RuntimeMacro.java:218)
      >> at org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:175)
      >> at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:336)
      >> at org.apache.velocity.runtime.directive.Parse.render(Parse.java:260)
      >> at org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:175)
      >> at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:336)
      >> at org.apache.velocity.Template.merge(Template.java:328)

      1. Velocity717TestCase.java
        3 kB
        Jarkko Viinamäki
      2. test8.vm
        0.1 kB
        Jarkko Viinamäki
      3. macros2.vm
        0.0 kB
        Jarkko Viinamäki

        Activity

        Hide
        Will Glass-Husain added a comment -

        Hi,

        I tried to replicate this issue and couldn't. I tried merging in a macro library with Template.merge() as you suggest. I also tried doing #parse in the included file and referencing the macro in the parent file. Neither generated an NPE.

        Can you please provide more details, ideally the VM and macro files you are using, and a code sample showing how you include the macros and merge the code.

        Show
        Will Glass-Husain added a comment - Hi, I tried to replicate this issue and couldn't. I tried merging in a macro library with Template.merge() as you suggest. I also tried doing #parse in the included file and referencing the macro in the parent file. Neither generated an NPE. Can you please provide more details, ideally the VM and macro files you are using, and a code sample showing how you include the macros and merge the code.
        Hide
        Will Glass-Husain added a comment -

        resolving. try with the latest version (from svn head). if you still have this difficulty, please reopen the bug and give a little more detail. Thanks!

        Show
        Will Glass-Husain added a comment - resolving. try with the latest version (from svn head). if you still have this difficulty, please reopen the bug and give a little more detail. Thanks!
        Hide
        Will Glass-Husain added a comment -

        I hit this recently in production code. I'm working to assemble a simple test case.

        Show
        Will Glass-Husain added a comment - I hit this recently in production code. I'm working to assemble a simple test case.
        Hide
        Jarkko Viinamäki added a comment -

        OK. I tracked down this bug. It happens in 1.6.2 but not in 1.7 (current head). To reproduce the bug is required that Velocity.VM_PERM_INLINE_LOCAL is set to true. Otherwise it doesn't happen as "namespaces" aren't enabled. See the attached testcase.

        The Parse directive is implemented differently in 1.7 (Is the behaviour still the same?) and it avoids this bug.

        The reason for this NPE is of course that the namespace parameter passed to VelocimacroManager.get is null. This eventually causes a call to Hashtable.get with a null key -> NPE.

        The bug is in runtime.directive.Parse:

        line 158: String arg = EventHandlerUtil.includeEvent( rsvc, context, sourcearg, context.getCurrentTemplateName(), getName());

        // now arg can be null if IncludeEventHandler returns null

        // then later in the same method

        line 254: macroLibraries.add(arg);

        Now the macroLibraries within the Context is "poisoned" by a null value. Then when we try to render some macro in runtime.directive.RuntimeMacro:

        line 218: o = rsvc.getVelocimacro(macroName,
        (String)macroLibraries.get, renderingTemplate);

        Here macroLibraries.get returns null and passes it to VelocimacroManager (namespace = null) and BOOM.

        Show
        Jarkko Viinamäki added a comment - OK. I tracked down this bug. It happens in 1.6.2 but not in 1.7 (current head). To reproduce the bug is required that Velocity.VM_PERM_INLINE_LOCAL is set to true. Otherwise it doesn't happen as "namespaces" aren't enabled. See the attached testcase. The Parse directive is implemented differently in 1.7 (Is the behaviour still the same?) and it avoids this bug. The reason for this NPE is of course that the namespace parameter passed to VelocimacroManager.get is null. This eventually causes a call to Hashtable.get with a null key -> NPE. The bug is in runtime.directive.Parse: line 158: String arg = EventHandlerUtil.includeEvent( rsvc, context, sourcearg, context.getCurrentTemplateName(), getName()); // now arg can be null if IncludeEventHandler returns null // then later in the same method line 254: macroLibraries.add(arg); Now the macroLibraries within the Context is "poisoned" by a null value. Then when we try to render some macro in runtime.directive.RuntimeMacro: line 218: o = rsvc.getVelocimacro(macroName, (String)macroLibraries.get , renderingTemplate); Here macroLibraries.get returns null and passes it to VelocimacroManager (namespace = null) and BOOM.
        Hide
        Jarkko Viinamäki added a comment -

        This same bug is obviously in all 1.6.x releases. The bug is not present in 1.5. It slipped in in revision 568691 (2007-08-22).

        Show
        Jarkko Viinamäki added a comment - This same bug is obviously in all 1.6.x releases. The bug is not present in 1.5. It slipped in in revision 568691 (2007-08-22).
        Hide
        Nathan Bubna added a comment -

        Well, we have other unreleased fixes in the 1.6 branch, might as well fix this too. Perhaps we can muster the votes and effort for a 1.6.4 release.

        Show
        Nathan Bubna added a comment - Well, we have other unreleased fixes in the 1.6 branch, might as well fix this too. Perhaps we can muster the votes and effort for a 1.6.4 release.
        Hide
        Nathan Bubna added a comment -

        Fixed. Thanks, Jarkko.

        Show
        Nathan Bubna added a comment - Fixed. Thanks, Jarkko.

          People

          • Assignee:
            Unassigned
            Reporter:
            Johann Weber
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development