You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by "Will Glass-Husain (JIRA)" <ji...@apache.org> on 2005/09/18 23:16:54 UTC
[jira] Updated: (VELOCITY-82) VM libs will not autoreload if unparseable at Velocity startup
[ http://issues.apache.org/jira/browse/VELOCITY-82?page=all ]
Will Glass-Husain updated VELOCITY-82:
--------------------------------------
Bugzilla Id: (was: 9451)
Fix Version: 1.5
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.
was:
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.
Environment:
Operating System: Linux
Platform: All
was:
Operating System: Linux
Platform: All
Assign To: (was: Velocity-Dev List)
Priority: Minor (was: Major)
Thanks for reporting this. Will look into it.
> VM libs will not autoreload if unparseable at Velocity startup
> --------------------------------------------------------------
>
> Key: VELOCITY-82
> URL: http://issues.apache.org/jira/browse/VELOCITY-82
> Project: Velocity
> Type: Bug
> Components: Source
> Versions: 1.3-rc1
> Environment: Operating System: Linux
> Platform: All
> Reporter: Michael Pearson
> Priority: Minor
> Fix For: 1.5
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org