[
https://issues.apache.org/jira/browse/VELOCITY-615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12654484#action_12654484
]
sohara edited comment on VELOCITY-615 at 12/8/08 9:54 AM:
----------------------------------------------------------------
We have upgraded to 1.6 but still have this issue.
I've condensed it down to the following;
#set($steve="old value")
#macro(tmpMacro $steve)
#set($steve="new value $steve")
$steve
#end
#tmpMacro("dave")
As you can see, there is some messing with the scope going on here but this is
in essence what is occurring in our application on a much larger scale.
I would expect the result to be "new value dave" but it's not, bizarrely it's
"dave"
This worked as expected in 1.5 and produced "new value dave"
Thes are my velocity settings;
objProps.setProperty("resource.loader", "Scaffold");
objProps.setProperty("Scaffold.resource.loader.class",
"com.pivotal.scaffold.ScaffoldResourceLoader");
objProps.setProperty("Scaffold.resource.loader.templatepath", sPath
+ "/WEB-INF/templates");
objProps.setProperty("Scaffold.resource.loader.reportpath", sPath +
"/WEB-INF/report");
objProps.setProperty("Scaffold.resource.loader.macrospath", sPath +
"/WEB-INF/macros");
objProps.setProperty("Scaffold.resource.loader.modificationCheckInterval",
"10");
objProps.setProperty("runtime.log.logsystem.class",
"org.apache.velocity.runtime.log.Log4JLogChute");
objProps.setProperty("runtime.log.logsystem.log4j.category",
"org.apache.velocity");
objProps.setProperty("velocimacro.permissions.allow.inline",
"true");
objProps.setProperty("velocimacro.permissions.allow.inline.to.replace.global",
"false");
objProps.setProperty("velocimacro.permissions.allow.inline.local.scope",
"true");
objProps.setProperty("velocimacro.context.localscope", "false");
objProps.setProperty("velocimacro.arguments.strict", "true");
objProps.setProperty("input.encoding",
ScaffoldApplication.DEFAULT_ENCODING);
objProps.setProperty("output.encoding",
ScaffoldApplication.DEFAULT_ENCODING);
objProps.setProperty("directive.parse.max.depth", "1000");
was (Author: sohara):
We have upgraded to 1.6 but still have this issue.
I've condensed it down to the following;
#set($steve="old value")
#macro(tmpMacro $steve)
#set($steve="new value $steve")
$steve
#end
#tmpMacro("dave")
As you can see, there is some messing with the scope going on here but this is
in essence what is occurring in our application on a much larger scale.
I would expect the result to be "new value dave" but it's not, bizarrely it's
"dave"
This worked as expected in 1.5 and produced "new value dave"
> Inconsistent macro bahaviour in cached and non-cached modes
> -----------------------------------------------------------
>
> Key: VELOCITY-615
> URL: https://issues.apache.org/jira/browse/VELOCITY-615
> Project: Velocity
> Issue Type: Bug
> Components: Engine
> Affects Versions: 1.5
> Environment: Windows XP, Tomcat 6.x, JVM 1.6
> Reporter: Steve O'Hara
> Fix For: 1.6
>
>
> Here's the scenario; we have a framework that allows us to reload the
> Velocity runtime so that we can tinker with caching etc at runtime. We
> normally run development with template caching turned off and deliver to the
> client with caching turned on.
> There is a problem with inline macros (probably macro libraries too, not
> sure) whereby they will behave differently once they are compiled and cached
> then when they are interpreted at runtime. It is all to do with the
> re-assignment of parameter variables within the macro.
> Here is a very simple example;
> #macro(tmpMacro $FieldNames)
> #set($FieldNames="ingredient." +
> $FieldNames.replaceAll(",",",ingredient."))
> .....
> #end
> #tmpMacro("one,two,three")
> This works fine when the template is not cached - as soon as you turn on
> caching, the macro becomes unreliable.
> My original prognosis was that we were upsetting the variable types by
> converting strings into lists but as you can see, that isn't the case in this
> example. The problem is solved by changing the assignment to;
> #set($Names="ingredient." + $FieldNames.replaceAll(",",",ingredient."))
> I can appreciate that maybe this type of "re-assignment" of parameters might
> be an issue, but the real problem is the inconsistency between the cached and
> non-cached behaviours.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
