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

        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.
        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.

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development