Velocity
  1. Velocity
  2. VELOCITY-277

macros in #parsed files are not refreshed when including page is refreshed

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 1.4
    • Fix Version/s: 1.6
    • Component/s: Engine
    • Labels:
      None
    • Environment:
      Operating System: other
      Platform: Other

      Description

      If a template #parses a file containing velocimacros, changes those macros do
      not make it into the including template. This is true whether the file is
      included via the library property or via #parse.

      Although there is the velocimacro.library.autoreload property, it is "not for
      use in production" according to the documentation - and cannot be used with
      template caching.

      Also, often, macros included via #parse do not pick up their macros the first
      time they are compiiled. And with template caching they are only ever called
      once, this leads to situations where changes in templates that include macros
      and are cached do not function in production.

        Issue Links

          Activity

          Hide
          Will Glass-Husain added a comment -

          Commenting on this old bug...

          I think the semantics of "velocimacro.library.autoreload" are clear. The real problem is your statement that "macros included via #parse" are not picked up. If this is fixed, I think you'd be ok.

          I know it's been a while, but can you supply a test case for this?

          Show
          Will Glass-Husain added a comment - Commenting on this old bug... I think the semantics of "velocimacro.library.autoreload" are clear. The real problem is your statement that "macros included via #parse" are not picked up. If this is fixed, I think you'd be ok. I know it's been a while, but can you supply a test case for this?
          Hide
          Tim White added a comment -

          Hey Will - I agree, if macros in #parsed files got picked up when template caching was on, this would be fixed.

          Up to my eyeballs at the moment, don't really have a simple test case handy.

          IIRC, if you load your templates from the filesystem, turn template caching on, put some velocimacros in one .vm, and include that .vm via #parse in another, you will have a test case.

          Seems like when updating a cached .vm from the file system, it doesn't parse it for macros. You end up getting a bunch of "macro undefined" in the main file, since the included file isn't parsed.

          It works fine the first time you start up the app, becuase everything gets parsed. But, if you update the included .vm (the one with the macros in it), without restarting the app, you will get the error.

          Something like this:

          master.vm:
          #parse("templates/macros.vm")
          #someMacro(arg)

          macros.vm:
          #macro(someMacro $arg)
          <p>Foo</p>
          #end

          Start up app with template caching on, load master.vm in your browser:

          Foo

          Update macros.vm with the app running:

          macros.vm:
          #macro(someMacro $arg)
          <p>Bar</p>
          #end

          Then try and load master.vm:

          #someMacro is undefined

          Show
          Tim White added a comment - Hey Will - I agree, if macros in #parsed files got picked up when template caching was on, this would be fixed. Up to my eyeballs at the moment, don't really have a simple test case handy. IIRC, if you load your templates from the filesystem, turn template caching on, put some velocimacros in one .vm, and include that .vm via #parse in another, you will have a test case. Seems like when updating a cached .vm from the file system, it doesn't parse it for macros. You end up getting a bunch of "macro undefined" in the main file, since the included file isn't parsed. It works fine the first time you start up the app, becuase everything gets parsed. But, if you update the included .vm (the one with the macros in it), without restarting the app, you will get the error. Something like this: master.vm: #parse("templates/macros.vm") #someMacro(arg) macros.vm: #macro(someMacro $arg) <p>Foo</p> #end Start up app with template caching on, load master.vm in your browser: Foo Update macros.vm with the app running: macros.vm: #macro(someMacro $arg) <p>Bar</p> #end Then try and load master.vm: #someMacro is undefined
          Hide
          Randy Watler added a comment -

          Jetspeed2 also has this problem while using the tools VelocityViewServlet to render portal content.

          To get around the issue, we manage our own set of VelocityEngine instances and use them to override/implement these methods:

          org.apache.velocity.tools.view.servlet.VelocityViewServlet.getTemplate(java.lang.String)
          org.apache.velocity.tools.view.servlet.VelocityViewServlet.getTemplate(java.lang.String, java.lang.String)

          We monitor file modifications dates of the macro files associated with the VelocityEngine and allocate new instances when the modifification is detected.

          Within the portal content templates, the following is used to load the macros:

          #parse($decoration.getResource("decorator-macros.vm"))

          We have already worked around this issue, but we would like to have this fixed so that we can let Velocity manage this!

          Show
          Randy Watler added a comment - Jetspeed2 also has this problem while using the tools VelocityViewServlet to render portal content. To get around the issue, we manage our own set of VelocityEngine instances and use them to override/implement these methods: org.apache.velocity.tools.view.servlet.VelocityViewServlet.getTemplate(java.lang.String) org.apache.velocity.tools.view.servlet.VelocityViewServlet.getTemplate(java.lang.String, java.lang.String) We monitor file modifications dates of the macro files associated with the VelocityEngine and allocate new instances when the modifification is detected. Within the portal content templates, the following is used to load the macros: #parse($decoration.getResource("decorator-macros.vm")) We have already worked around this issue, but we would like to have this fixed so that we can let Velocity manage this!
          Hide
          Will Glass-Husain added a comment -

          I added some thoughts on resolving this to the Wiki.
          http://wiki.apache.org/jakarta-velocity/MacroIssues

          Show
          Will Glass-Husain added a comment - I added some thoughts on resolving this to the Wiki. http://wiki.apache.org/jakarta-velocity/MacroIssues
          Hide
          Will Glass-Husain added a comment -

          Upon reflection, this is trickier than it seems and is not a bug but more of a design issue. Moving to version 1.6.

          Show
          Will Glass-Husain added a comment - Upon reflection, this is trickier than it seems and is not a bug but more of a design issue. Moving to version 1.6.
          Hide
          Henning Schmiedehausen added a comment -

          The issue is a known problem and already documented on the wiki. Closing the issue report.

          Show
          Henning Schmiedehausen added a comment - The issue is a known problem and already documented on the wiki. Closing the issue report.
          Hide
          Will Glass-Husain added a comment -

          As discussed on the dev list, I see this as an important "todo" for 1.6. I've reopened this issue and Velocity-362 as a reminder of this. (they seem to hit slightly different aspects of the problem).

          Show
          Will Glass-Husain added a comment - As discussed on the dev list, I see this as an important "todo" for 1.6. I've reopened this issue and Velocity-362 as a reminder of this. (they seem to hit slightly different aspects of the problem).
          Hide
          Will Glass-Husain added a comment -

          This is fixed and in svn head. More details in Velocity.362.

          Show
          Will Glass-Husain added a comment - This is fixed and in svn head. More details in Velocity.362.

            People

            • Assignee:
              Unassigned
              Reporter:
              Tim White
            • Votes:
              2 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development