Velocity
  1. Velocity
  2. VELOCITY-82

VM libs will not autoreload if unparseable at Velocity startup

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Later
    • Affects Version/s: 1.3-rc1
    • Fix Version/s: 2.x
    • Component/s: Engine
    • Labels:
      None
    • Environment:
      Operating System: Linux
      Platform: All

      Description

      I'm using Velocity 1.3-rc1 (updated from CVS (tag TVEL_1_3_BRANCH) as at 28th of
      May, 2002) on a Redhat 7.2 system, combined with velocity-tools/struts and
      velocity-tools/view from latest cvs.

      When a velocimacro library is loaded at initialisation time, it is normally
      added to the libModMap hash in VelocimacroFactory. The libModMap hash is checked
      when reloading velocimacro templates. However, if the parsing of the velocimacro
      library fails midway through, the macros are added to the namespace but the
      Template is not returned to VelocimacroFactory, and thus not added to libModMap.
      This means that if a VM library is broken at initialization time, it will never
      be reloaded until Velocity is restarted.

      I have not tried this under the HEAD tagged CVS sources, as my macros refuse to
      parse at all using this branch.

        Activity

        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open Resolved Resolved
        1598d 2h 29m 1 Henning Schmiedehausen 12/Oct/06 15:38
        Mark Thomas made changes -
        Workflow Default workflow, editable Closed status [ 12551828 ] jira [ 12552298 ]
        Mark Thomas made changes -
        Workflow jira [ 12324957 ] Default workflow, editable Closed status [ 12551828 ]
        Henning Schmiedehausen made changes -
        Fix Version/s 1.5 [ 12310253 ]
        Resolution Later [ 7 ]
        Status Open [ 1 ] Resolved [ 5 ]
        Fix Version/s 2.0 [ 12310291 ]
        Hide
        Henning Schmiedehausen added a comment -

        The problem here is twofold and IMHO fixing it for 1.5 is hard.

        First, this is an error. If a macro library that is supposed to be loaded cannot be loaded for whatever reason, it is debatable whether this is actually a fatal error and it shouldn't just report in the log file but stop the initialization of the engine altogether. Will proposed the creation of a VelocityInitException which would be thrown in that case.

        Second, fixing it so that the cache notices "there is a macro library available though this resource loader, but it is currently buggy, let's go back after the check interval and see if this has changed" at init time is hard. If an existing library that parsed fine the first time gets broken, then the cache simply keeps the last good version (it is argueable whether this is the right behaviour, too). But if there is no good version in the first place, the current internal mechanism of loading resources have to be rewritten (differentiate between "unloaded" -> "loaded, but not yet parsed" -> "parsed"). I'm afraid that is out of the question for 1.5 and probably most of the 1.x series.

        Show
        Henning Schmiedehausen added a comment - The problem here is twofold and IMHO fixing it for 1.5 is hard. First, this is an error. If a macro library that is supposed to be loaded cannot be loaded for whatever reason, it is debatable whether this is actually a fatal error and it shouldn't just report in the log file but stop the initialization of the engine altogether. Will proposed the creation of a VelocityInitException which would be thrown in that case. Second, fixing it so that the cache notices "there is a macro library available though this resource loader, but it is currently buggy, let's go back after the check interval and see if this has changed" at init time is hard. If an existing library that parsed fine the first time gets broken, then the cache simply keeps the last good version (it is argueable whether this is the right behaviour, too). But if there is no good version in the first place, the current internal mechanism of loading resources have to be rewritten (differentiate between "unloaded" -> "loaded, but not yet parsed" -> "parsed"). I'm afraid that is out of the question for 1.5 and probably most of the 1.x series.
        Will Glass-Husain made changes -
        Fix Version/s 1.5 [ 12310253 ]
        Assignee Velocity-Dev List [ velocity-dev@jakarta.apache.org ]
        Environment Operating System: Linux
        Platform: All
        Operating System: Linux
        Platform: All
        Priority Major [ 3 ] Minor [ 4 ]
        Bugzilla Id 9451
        Description I'm using Velocity 1.3-rc1 (updated from CVS (tag TVEL_1_3_BRANCH) as at 28th of
        May, 2002) on a Redhat 7.2 system, combined with velocity-tools/struts and
        velocity-tools/view from latest cvs.

        When a velocimacro library is loaded at initialisation time, it is normally
        added to the libModMap hash in VelocimacroFactory. The libModMap hash is checked
        when reloading velocimacro templates. However, if the parsing of the velocimacro
        library fails midway through, the macros are added to the namespace but the
        Template is not returned to VelocimacroFactory, and thus not added to libModMap.
        This means that if a VM library is broken at initialization time, it will never
        be reloaded until Velocity is restarted.

        I have not tried this under the HEAD tagged CVS sources, as my macros refuse to
        parse at all using this branch.
        I'm using Velocity 1.3-rc1 (updated from CVS (tag TVEL_1_3_BRANCH) as at 28th of
        May, 2002) on a Redhat 7.2 system, combined with velocity-tools/struts and
        velocity-tools/view from latest cvs.

        When a velocimacro library is loaded at initialisation time, it is normally
        added to the libModMap hash in VelocimacroFactory. The libModMap hash is checked
        when reloading velocimacro templates. However, if the parsing of the velocimacro
        library fails midway through, the macros are added to the namespace but the
        Template is not returned to VelocimacroFactory, and thus not added to libModMap.
        This means that if a VM library is broken at initialization time, it will never
        be reloaded until Velocity is restarted.

        I have not tried this under the HEAD tagged CVS sources, as my macros refuse to
        parse at all using this branch.
        Hide
        Will Glass-Husain added a comment -

        Thanks for reporting this. Will look into it.

        Show
        Will Glass-Husain added a comment - Thanks for reporting this. Will look into it.
        Jeff Turner made changes -
        Field Original Value New Value
        issue.field.bugzillaimportkey 9451 12314952
        Michael Pearson created issue -

          People

          • Assignee:
            Unassigned
            Reporter:
            Michael Pearson
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development