You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by "Steve O'Hara (JIRA)" <de...@velocity.apache.org> on 2008/09/18 13:03:44 UTC
[jira] Created: (VELOCITY-615) Inconsistent macro bahaviour in
cached and non-cached modes
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
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: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
[jira] Commented: (VELOCITY-615) Inconsistent macro bahaviour in
cached and non-cached modes
Posted by "Will Glass-Husain (JIRA)" <de...@velocity.apache.org>.
[ https://issues.apache.org/jira/browse/VELOCITY-615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12632278#action_12632278 ]
Will Glass-Husain commented on VELOCITY-615:
--------------------------------------------
Have you tried this with the upcoming v 1.6 (download from subversion)? There's been a lot of work to shore up the macro infrastructure.
WILL
> 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
>
> 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: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
[jira] Reopened: (VELOCITY-615) Inconsistent macro bahaviour in
cached and non-cached modes
Posted by "Steve O'Hara (JIRA)" <de...@velocity.apache.org>.
[ https://issues.apache.org/jira/browse/VELOCITY-615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Steve O'Hara reopened VELOCITY-615:
-----------------------------------
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: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
[jira] Resolved: (VELOCITY-615) Inconsistent macro bahaviour in
cached and non-cached modes
Posted by "Nathan Bubna (JIRA)" <de...@velocity.apache.org>.
[ https://issues.apache.org/jira/browse/VELOCITY-615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Nathan Bubna resolved VELOCITY-615.
-----------------------------------
Resolution: Cannot Reproduce
Fix Version/s: 1.6
I'm not seeing this with 1.6, though admittedly, i'm not sure i fully understand what needs to happen to replicate it. Steve, if this is still a problem for you in 1.6, please re-open this, so we can investigate further.
> 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: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
[jira] Issue Comment Edited: (VELOCITY-615) Inconsistent macro
bahaviour in cached and non-cached modes
Posted by "Steve O'Hara (JIRA)" <de...@velocity.apache.org>.
[ 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: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
[jira] Resolved: (VELOCITY-615) Inconsistent macro bahaviour in
cached and non-cached modes
Posted by "Nathan Bubna (JIRA)" <de...@velocity.apache.org>.
[ https://issues.apache.org/jira/browse/VELOCITY-615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Nathan Bubna resolved VELOCITY-615.
-----------------------------------
Resolution: Fixed
Fix Version/s: (was: 1.6)
1.7
1.6.1
> 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.1, 1.7
>
>
> 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: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
[jira] Commented: (VELOCITY-615) Inconsistent macro bahaviour in
cached and non-cached modes
Posted by "Nathan Bubna (JIRA)" <de...@velocity.apache.org>.
[ https://issues.apache.org/jira/browse/VELOCITY-615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12632292#action_12632292 ]
Nathan Bubna commented on VELOCITY-615:
---------------------------------------
You can also get a candidate for 1.6-beta1 at:
http://people.apache.org/~nbubna/velocity/engine/1.6-beta1/
The way macros are handled under the covers has changed dramatically. Please try out 1.6.
> 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
>
> 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: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
[jira] Commented: (VELOCITY-615) Inconsistent macro bahaviour in
cached and non-cached modes
Posted by "Nathan Bubna (JIRA)" <de...@velocity.apache.org>.
[ https://issues.apache.org/jira/browse/VELOCITY-615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12654534#action_12654534 ]
Nathan Bubna commented on VELOCITY-615:
---------------------------------------
So, i can understand why you would expect this to work, but it sure ain't pretty to have everything named $foo. You have a global $foo, then 'dave' proxied as a $foo macro argument and then changing the value of $foo. It appears that this is confusing ProxyVMContext. I think you'll notice some errors in your logs letting you know this isn't working for it. So, at least there's a warning about this.
You'll find that changing it to:
#set($steve="old value")
#macro(tmpMacro $bob)
#set($steve="new value $bob")
$steve
#end
#tmpMacro("dave")
Should fix your problem.
In the meantime, i'll see if i can impart some greater wisdom to ProxyVMContext regarding the tangled web you've woven. I can't see any good reason this should be disallowed, tangled though it is.
i also don't see how this latest example has anything to do with cached vs non-cached modes. I can replicate it just fine in non-cached mode. this is clearly different than the original bug you experienced in 1.5.
> 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: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org