[jira] Commented: (VELOCITY-537) Multi-line comments causing ParseException in macros in Velocity engine 1.5
[ https://issues.apache.org/jira/browse/VELOCITY-537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12570997#action_12570997 ] Marnix van Bochove commented on VELOCITY-537: - I found a solution to this problem (and the underlying issue as mentioned in issue VELOCITY-580: The problem is when method getASTAsStringArray(Node rootNode) of class Macro (package org.apache.velocity.runtime.directive) is called to produce a List of Strings, for some reason a string "*#" appears. This string is coming from a ASTComment node which has a token whose image is "*#". I don't know if ASTComment is parsed invalid or the image of the token is wrong, but when changing method NodeUtils.tokenLiteral( Token t ) (in package org.apache.velocity.runtime.parser.node) to this: public static String tokenLiteral( Token t ) { String result; // Issue: VELOCITY-580 // Marnix 2008-02-20: Look at king of token and return "" when it's a multiline comment if (t.kind == ParserConstants.MULTI_LINE_COMMENT) { result = ""; } else { result = specialText( t ) + t.image; } return result; } the problem of "*#" in macro output will disappear. Another solution could be, to change the image of the first token inside a ASTComment Node. > Multi-line comments causing ParseException in macros in Velocity engine 1.5 > --- > > Key: VELOCITY-537 > URL: https://issues.apache.org/jira/browse/VELOCITY-537 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 1.5 >Reporter: Christopher Townson > Fix For: 1.5.1 > > > Moving from velocity engine 1.4 to 1.5, one of my macros is now causing a > ParseException: > #macro( makeLink $filepath )#* > *##if ($request.serverName.equalsIgnoreCase("www.liveserver.com") || > $request.serverName.equalsIgnoreCase("liveserver.com"))#* > *##set($mirrorDomain = "livemirror.com")#* > *##elseif($request.serverName.equalsIgnoreCase("stagingserver.com"))#* > *##set($mirrorDomain = "stagingmirror.com")#* > *##elseif($request.serverName.equalsIgnoreCase("devserver.com") || > $request.serverName.equalsIgnoreCase("localhost"))#* > *##set($mirrorDomain = "devmirror.com")#* > *##else#* > *##set($mirrorDomain = "liveserver.com")#* > *##end#* > *#http://${mirrorDomain}${filepath}#* > *##end > This macro uses the mutli-line comment hack to gobble whitespace (so that > none appears in the link text, whilst preserving some kind of readability. > This works fine in 1.4, but throws a ParseException in 1.5 (stacktrace below) > -- stacktrace -- > 2007-04-03 16:05:38,712 - VelocimacroManager.parseTree() : exception makeLink > org.apache.velocity.runtime.parser.ParseException: Lexical error: > org.apache.velocity.runtime.parser.TokenMgrError: Lexical error at line 1, > column 535. Encountered: after : "" > at org.apache.velocity.runtime.parser.Parser.parse(Parser.java:124) > at > org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:1042) > at > org.apache.velocity.runtime.directive.VelocimacroProxy.parseTree(VelocimacroProxy.java:342) > at > org.apache.velocity.runtime.directive.VelocimacroProxy.setupMacro(VelocimacroProxy.java:322) > at > org.apache.velocity.runtime.directive.VelocimacroProxy.init(VelocimacroProxy.java:309) > at > org.apache.velocity.runtime.parser.node.ASTDirective.init(ASTDirective.java:134) > at > org.apache.velocity.runtime.parser.node.SimpleNode.init(SimpleNode.java:285) > at org.apache.velocity.Template.initDocument(Template.java:199) > at org.apache.velocity.Template.process(Template.java:121) > at > org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:415) > at > org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:335) > at > org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1102) > at > org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1077) > at > org.apache.velocity.app.VelocityEngine.getTemplate(VelocityEngine.java:528) > at > org.apache.velocity.tools.view.servlet.VelocityViewServlet.getTemplate(VelocityViewServlet.java:667) > at > org.apache.velocity.tools.view.servlet.VelocityViewServlet.handleRequest(VelocityViewServlet.java:601) > at > org.apache.velocity.tools.view.servlet.VelocityViewServlet.doRequest(VelocityViewServlet.java:541) > at > org.apache.velocity.tools.view.servlet.VelocityViewServlet.doGet(VelocityViewServlet.java:507) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) > at javax.se
Re: Call a velocity macro
Nathan, Nathan Bubna wrote: I'm pretty sure #local is still just in Geir's whiteboard section. No one has ever gotten it promoted out of there. I've never been opposed to it, but i've also never been interested in putting the work needed into it (tests, docs, etc). I have to admit that when I started really writing macros (other than super simple ones), I was disappointed to learn that there was no "stack"... that is, I couldn't implement certain things properly using the macro facility because recursive calls would overwrite variables from what I would have considered "outer" scopes. If anyone is contemplating a "Velocity 2.x", I would seriously recommend that macros and other things (like #parse, #evaluate, and similar things) run in their own, local and inherited contexts. This gives much greater freedom to the developer, who doesn't have to worry about "temporary" variables within macros, etc. clobbering variables set in the caller's scope. It would be best if this were simply a language feature, instead of a hack provided through another directive (though it would have to be hacked in this way for Velocity 1.x, since some folks may actually rely on this inconvenient setup. -chris signature.asc Description: OpenPGP digital signature
[jira] Commented: (VELOCITY-537) Multi-line comments causing ParseException in macros in Velocity engine 1.5
[ https://issues.apache.org/jira/browse/VELOCITY-537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12571059#action_12571059 ] Christopher Schultz commented on VELOCITY-537: -- Marnix, I'm no expert in how Velocity parses and executes templates, but this seems like the kind of thing that should be fixed in the parser itself, not an AST walker. I'm not sure how the team feels, but I'm not sure there's a reason to do anything with comments but completely ignore them during the building of the AST. >From the stack trace, though, it looks like this is actually /during/ parsing, >rather than evaluation. That would indicate to me that the problem /is/ with the parser (probably the grammar). Is the method indicated in the previous comment automatically generated by javacc/antlr/jlex+cup or whatever compiler compiler we use? If so, the opportunities for fixing this bug in an auto-generated method are quite limited. > Multi-line comments causing ParseException in macros in Velocity engine 1.5 > --- > > Key: VELOCITY-537 > URL: https://issues.apache.org/jira/browse/VELOCITY-537 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 1.5 >Reporter: Christopher Townson > Fix For: 1.5.1 > > > Moving from velocity engine 1.4 to 1.5, one of my macros is now causing a > ParseException: > #macro( makeLink $filepath )#* > *##if ($request.serverName.equalsIgnoreCase("www.liveserver.com") || > $request.serverName.equalsIgnoreCase("liveserver.com"))#* > *##set($mirrorDomain = "livemirror.com")#* > *##elseif($request.serverName.equalsIgnoreCase("stagingserver.com"))#* > *##set($mirrorDomain = "stagingmirror.com")#* > *##elseif($request.serverName.equalsIgnoreCase("devserver.com") || > $request.serverName.equalsIgnoreCase("localhost"))#* > *##set($mirrorDomain = "devmirror.com")#* > *##else#* > *##set($mirrorDomain = "liveserver.com")#* > *##end#* > *#http://${mirrorDomain}${filepath}#* > *##end > This macro uses the mutli-line comment hack to gobble whitespace (so that > none appears in the link text, whilst preserving some kind of readability. > This works fine in 1.4, but throws a ParseException in 1.5 (stacktrace below) > -- stacktrace -- > 2007-04-03 16:05:38,712 - VelocimacroManager.parseTree() : exception makeLink > org.apache.velocity.runtime.parser.ParseException: Lexical error: > org.apache.velocity.runtime.parser.TokenMgrError: Lexical error at line 1, > column 535. Encountered: after : "" > at org.apache.velocity.runtime.parser.Parser.parse(Parser.java:124) > at > org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:1042) > at > org.apache.velocity.runtime.directive.VelocimacroProxy.parseTree(VelocimacroProxy.java:342) > at > org.apache.velocity.runtime.directive.VelocimacroProxy.setupMacro(VelocimacroProxy.java:322) > at > org.apache.velocity.runtime.directive.VelocimacroProxy.init(VelocimacroProxy.java:309) > at > org.apache.velocity.runtime.parser.node.ASTDirective.init(ASTDirective.java:134) > at > org.apache.velocity.runtime.parser.node.SimpleNode.init(SimpleNode.java:285) > at org.apache.velocity.Template.initDocument(Template.java:199) > at org.apache.velocity.Template.process(Template.java:121) > at > org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:415) > at > org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:335) > at > org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1102) > at > org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1077) > at > org.apache.velocity.app.VelocityEngine.getTemplate(VelocityEngine.java:528) > at > org.apache.velocity.tools.view.servlet.VelocityViewServlet.getTemplate(VelocityViewServlet.java:667) > at > org.apache.velocity.tools.view.servlet.VelocityViewServlet.handleRequest(VelocityViewServlet.java:601) > at > org.apache.velocity.tools.view.servlet.VelocityViewServlet.doRequest(VelocityViewServlet.java:541) > at > org.apache.velocity.tools.view.servlet.VelocityViewServlet.doGet(VelocityViewServlet.java:507) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java
[jira] Commented: (VELOCITY-537) Multi-line comments causing ParseException in macros in Velocity engine 1.5
[ https://issues.apache.org/jira/browse/VELOCITY-537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12571109#action_12571109 ] Marnix van Bochove commented on VELOCITY-537: - Christopher, I think the ASTComment node should not be in the list, so I agree it's probably a problem with the parser. I don't know how the tokenLiteral method is generated or not. > Multi-line comments causing ParseException in macros in Velocity engine 1.5 > --- > > Key: VELOCITY-537 > URL: https://issues.apache.org/jira/browse/VELOCITY-537 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 1.5 >Reporter: Christopher Townson > Fix For: 1.5.1 > > > Moving from velocity engine 1.4 to 1.5, one of my macros is now causing a > ParseException: > #macro( makeLink $filepath )#* > *##if ($request.serverName.equalsIgnoreCase("www.liveserver.com") || > $request.serverName.equalsIgnoreCase("liveserver.com"))#* > *##set($mirrorDomain = "livemirror.com")#* > *##elseif($request.serverName.equalsIgnoreCase("stagingserver.com"))#* > *##set($mirrorDomain = "stagingmirror.com")#* > *##elseif($request.serverName.equalsIgnoreCase("devserver.com") || > $request.serverName.equalsIgnoreCase("localhost"))#* > *##set($mirrorDomain = "devmirror.com")#* > *##else#* > *##set($mirrorDomain = "liveserver.com")#* > *##end#* > *#http://${mirrorDomain}${filepath}#* > *##end > This macro uses the mutli-line comment hack to gobble whitespace (so that > none appears in the link text, whilst preserving some kind of readability. > This works fine in 1.4, but throws a ParseException in 1.5 (stacktrace below) > -- stacktrace -- > 2007-04-03 16:05:38,712 - VelocimacroManager.parseTree() : exception makeLink > org.apache.velocity.runtime.parser.ParseException: Lexical error: > org.apache.velocity.runtime.parser.TokenMgrError: Lexical error at line 1, > column 535. Encountered: after : "" > at org.apache.velocity.runtime.parser.Parser.parse(Parser.java:124) > at > org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:1042) > at > org.apache.velocity.runtime.directive.VelocimacroProxy.parseTree(VelocimacroProxy.java:342) > at > org.apache.velocity.runtime.directive.VelocimacroProxy.setupMacro(VelocimacroProxy.java:322) > at > org.apache.velocity.runtime.directive.VelocimacroProxy.init(VelocimacroProxy.java:309) > at > org.apache.velocity.runtime.parser.node.ASTDirective.init(ASTDirective.java:134) > at > org.apache.velocity.runtime.parser.node.SimpleNode.init(SimpleNode.java:285) > at org.apache.velocity.Template.initDocument(Template.java:199) > at org.apache.velocity.Template.process(Template.java:121) > at > org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:415) > at > org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:335) > at > org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1102) > at > org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1077) > at > org.apache.velocity.app.VelocityEngine.getTemplate(VelocityEngine.java:528) > at > org.apache.velocity.tools.view.servlet.VelocityViewServlet.getTemplate(VelocityViewServlet.java:667) > at > org.apache.velocity.tools.view.servlet.VelocityViewServlet.handleRequest(VelocityViewServlet.java:601) > at > org.apache.velocity.tools.view.servlet.VelocityViewServlet.doRequest(VelocityViewServlet.java:541) > at > org.apache.velocity.tools.view.servlet.VelocityViewServlet.doGet(VelocityViewServlet.java:507) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) > at > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) > at
Re: Call a velocity macro
On Thu, Feb 21, 2008 at 6:36 AM, Christopher Schultz <[EMAIL PROTECTED]> wrote: > Nathan, > > > Nathan Bubna wrote: > > I'm pretty sure #local is still just in Geir's whiteboard section. No > > one has ever gotten it promoted out of there. I've never been opposed > > to it, but i've also never been interested in putting the work needed > > into it (tests, docs, etc). > > I have to admit that when I started really writing macros (other than > super simple ones), I was disappointed to learn that there was no > "stack"... that is, I couldn't implement certain things properly using > the macro facility because recursive calls would overwrite variables > from what I would have considered "outer" scopes. > > If anyone is contemplating a "Velocity 2.x", I would seriously recommend > that macros and other things (like #parse, #evaluate, and similar > things) run in their own, local and inherited contexts. This gives much > greater freedom to the developer, who doesn't have to worry about > "temporary" variables within macros, etc. clobbering variables set in > the caller's scope. > > It would be best if this were simply a language feature, instead of a > hack provided through another directive (though it would have to be > hacked in this way for Velocity 1.x, since some folks may actually rely > on this inconvenient setup. inconvenience is sometimes a matter of perspective, and you might soon find people providing special #setglobal hacks for when they do want to clobber a variable in the caller's scope. personally, i've always been able to see this both ways and never had much trouble adjusting to the lack of scoping. when my macros/layouts/parses ever get complicated enough that i can't track all the variables, i just start namespacing ones i want to keep 'local'. anyway, being able to see both sides and easily adjust either way, you probably won't ever find me motivated to work on this or object to anyone else working to change this in a theoretical 2.x version. namespaces or scoping, i'm good either way. :) > -chris > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Call a velocity macro
Wait - that's not true You certainly can do scoped velocimacros... geir On Feb 21, 2008, at 12:57 PM, Nathan Bubna wrote: On Thu, Feb 21, 2008 at 6:36 AM, Christopher Schultz <[EMAIL PROTECTED]> wrote: Nathan, Nathan Bubna wrote: I'm pretty sure #local is still just in Geir's whiteboard section. No one has ever gotten it promoted out of there. I've never been opposed to it, but i've also never been interested in putting the work needed into it (tests, docs, etc). I have to admit that when I started really writing macros (other than super simple ones), I was disappointed to learn that there was no "stack"... that is, I couldn't implement certain things properly using the macro facility because recursive calls would overwrite variables from what I would have considered "outer" scopes. If anyone is contemplating a "Velocity 2.x", I would seriously recommend that macros and other things (like #parse, #evaluate, and similar things) run in their own, local and inherited contexts. This gives much greater freedom to the developer, who doesn't have to worry about "temporary" variables within macros, etc. clobbering variables set in the caller's scope. It would be best if this were simply a language feature, instead of a hack provided through another directive (though it would have to be hacked in this way for Velocity 1.x, since some folks may actually rely on this inconvenient setup. inconvenience is sometimes a matter of perspective, and you might soon find people providing special #setglobal hacks for when they do want to clobber a variable in the caller's scope. personally, i've always been able to see this both ways and never had much trouble adjusting to the lack of scoping. when my macros/layouts/parses ever get complicated enough that i can't track all the variables, i just start namespacing ones i want to keep 'local'. anyway, being able to see both sides and easily adjust either way, you probably won't ever find me motivated to work on this or object to anyone else working to change this in a theoretical 2.x version. namespaces or scoping, i'm good either way. :) -chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Call a velocity macro
Yeah, sorry. I forget about that, since i've been avoiding macros for some time and never actually bothered with this property: velocimacro.context.localscope = true On Thu, Feb 21, 2008 at 9:59 AM, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > Wait - that's not true You certainly can do scoped velocimacros... > > geir > > > > On Feb 21, 2008, at 12:57 PM, Nathan Bubna wrote: > > > On Thu, Feb 21, 2008 at 6:36 AM, Christopher Schultz > > <[EMAIL PROTECTED]> wrote: > >> Nathan, > >> > >> > >> Nathan Bubna wrote: > >>> I'm pretty sure #local is still just in Geir's whiteboard > >>> section. No > >>> one has ever gotten it promoted out of there. I've never been > >>> opposed > >>> to it, but i've also never been interested in putting the work > >>> needed > >>> into it (tests, docs, etc). > >> > >> I have to admit that when I started really writing macros (other than > >> super simple ones), I was disappointed to learn that there was no > >> "stack"... that is, I couldn't implement certain things properly > >> using > >> the macro facility because recursive calls would overwrite variables > >> from what I would have considered "outer" scopes. > >> > >> If anyone is contemplating a "Velocity 2.x", I would seriously > >> recommend > >> that macros and other things (like #parse, #evaluate, and similar > >> things) run in their own, local and inherited contexts. This gives > >> much > >> greater freedom to the developer, who doesn't have to worry about > >> "temporary" variables within macros, etc. clobbering variables set in > >> the caller's scope. > >> > >> It would be best if this were simply a language feature, instead of a > >> hack provided through another directive (though it would have to be > >> hacked in this way for Velocity 1.x, since some folks may actually > >> rely > >> on this inconvenient setup. > > > > inconvenience is sometimes a matter of perspective, and you might soon > > find people providing special #setglobal hacks for when they do want > > to clobber a variable in the caller's scope. personally, i've always > > been able to see this both ways and never had much trouble adjusting > > to the lack of scoping. when my macros/layouts/parses ever get > > complicated enough that i can't track all the variables, i just start > > namespacing ones i want to keep 'local'. > > > > anyway, being able to see both sides and easily adjust either way, you > > probably won't ever find me motivated to work on this or object to > > anyone else working to change this in a theoretical 2.x version. > > namespaces or scoping, i'm good either way. :) > > > >> -chris > >> > >> > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-537) Multi-line comments causing ParseException in macros in Velocity engine 1.5
[ https://issues.apache.org/jira/browse/VELOCITY-537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12571145#action_12571145 ] Nathan Bubna commented on VELOCITY-537: --- NodeUtils.tokenLiteral() is not a generated class/method. But it does seem odd to have the fix here when the problem seems to be rooted from elsewhere. Still, if it fixes it and no one steps up to dig for the root issue, then i'd support including this fix. Better a workaround than nothing! Marnix, do you think you could whip up a test case to go with this patch (well, it's sort of a patch :)? > Multi-line comments causing ParseException in macros in Velocity engine 1.5 > --- > > Key: VELOCITY-537 > URL: https://issues.apache.org/jira/browse/VELOCITY-537 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 1.5 >Reporter: Christopher Townson > Fix For: 1.5.1 > > > Moving from velocity engine 1.4 to 1.5, one of my macros is now causing a > ParseException: > #macro( makeLink $filepath )#* > *##if ($request.serverName.equalsIgnoreCase("www.liveserver.com") || > $request.serverName.equalsIgnoreCase("liveserver.com"))#* > *##set($mirrorDomain = "livemirror.com")#* > *##elseif($request.serverName.equalsIgnoreCase("stagingserver.com"))#* > *##set($mirrorDomain = "stagingmirror.com")#* > *##elseif($request.serverName.equalsIgnoreCase("devserver.com") || > $request.serverName.equalsIgnoreCase("localhost"))#* > *##set($mirrorDomain = "devmirror.com")#* > *##else#* > *##set($mirrorDomain = "liveserver.com")#* > *##end#* > *#http://${mirrorDomain}${filepath}#* > *##end > This macro uses the mutli-line comment hack to gobble whitespace (so that > none appears in the link text, whilst preserving some kind of readability. > This works fine in 1.4, but throws a ParseException in 1.5 (stacktrace below) > -- stacktrace -- > 2007-04-03 16:05:38,712 - VelocimacroManager.parseTree() : exception makeLink > org.apache.velocity.runtime.parser.ParseException: Lexical error: > org.apache.velocity.runtime.parser.TokenMgrError: Lexical error at line 1, > column 535. Encountered: after : "" > at org.apache.velocity.runtime.parser.Parser.parse(Parser.java:124) > at > org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:1042) > at > org.apache.velocity.runtime.directive.VelocimacroProxy.parseTree(VelocimacroProxy.java:342) > at > org.apache.velocity.runtime.directive.VelocimacroProxy.setupMacro(VelocimacroProxy.java:322) > at > org.apache.velocity.runtime.directive.VelocimacroProxy.init(VelocimacroProxy.java:309) > at > org.apache.velocity.runtime.parser.node.ASTDirective.init(ASTDirective.java:134) > at > org.apache.velocity.runtime.parser.node.SimpleNode.init(SimpleNode.java:285) > at org.apache.velocity.Template.initDocument(Template.java:199) > at org.apache.velocity.Template.process(Template.java:121) > at > org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:415) > at > org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:335) > at > org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1102) > at > org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1077) > at > org.apache.velocity.app.VelocityEngine.getTemplate(VelocityEngine.java:528) > at > org.apache.velocity.tools.view.servlet.VelocityViewServlet.getTemplate(VelocityViewServlet.java:667) > at > org.apache.velocity.tools.view.servlet.VelocityViewServlet.handleRequest(VelocityViewServlet.java:601) > at > org.apache.velocity.tools.view.servlet.VelocityViewServlet.doRequest(VelocityViewServlet.java:541) > at > org.apache.velocity.tools.view.servlet.VelocityViewServlet.doGet(VelocityViewServlet.java:507) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) > at > org.apache.catalina.core.StandardEngineValve.invoke(Standard
[jira] Commented: (VELOCITY-537) Multi-line comments causing ParseException in macros in Velocity engine 1.5
[ https://issues.apache.org/jira/browse/VELOCITY-537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12571170#action_12571170 ] Nathan Bubna commented on VELOCITY-537: --- A unit test would be great! > Multi-line comments causing ParseException in macros in Velocity engine 1.5 > --- > > Key: VELOCITY-537 > URL: https://issues.apache.org/jira/browse/VELOCITY-537 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 1.5 >Reporter: Christopher Townson > Fix For: 1.5.1 > > > Moving from velocity engine 1.4 to 1.5, one of my macros is now causing a > ParseException: > #macro( makeLink $filepath )#* > *##if ($request.serverName.equalsIgnoreCase("www.liveserver.com") || > $request.serverName.equalsIgnoreCase("liveserver.com"))#* > *##set($mirrorDomain = "livemirror.com")#* > *##elseif($request.serverName.equalsIgnoreCase("stagingserver.com"))#* > *##set($mirrorDomain = "stagingmirror.com")#* > *##elseif($request.serverName.equalsIgnoreCase("devserver.com") || > $request.serverName.equalsIgnoreCase("localhost"))#* > *##set($mirrorDomain = "devmirror.com")#* > *##else#* > *##set($mirrorDomain = "liveserver.com")#* > *##end#* > *#http://${mirrorDomain}${filepath}#* > *##end > This macro uses the mutli-line comment hack to gobble whitespace (so that > none appears in the link text, whilst preserving some kind of readability. > This works fine in 1.4, but throws a ParseException in 1.5 (stacktrace below) > -- stacktrace -- > 2007-04-03 16:05:38,712 - VelocimacroManager.parseTree() : exception makeLink > org.apache.velocity.runtime.parser.ParseException: Lexical error: > org.apache.velocity.runtime.parser.TokenMgrError: Lexical error at line 1, > column 535. Encountered: after : "" > at org.apache.velocity.runtime.parser.Parser.parse(Parser.java:124) > at > org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:1042) > at > org.apache.velocity.runtime.directive.VelocimacroProxy.parseTree(VelocimacroProxy.java:342) > at > org.apache.velocity.runtime.directive.VelocimacroProxy.setupMacro(VelocimacroProxy.java:322) > at > org.apache.velocity.runtime.directive.VelocimacroProxy.init(VelocimacroProxy.java:309) > at > org.apache.velocity.runtime.parser.node.ASTDirective.init(ASTDirective.java:134) > at > org.apache.velocity.runtime.parser.node.SimpleNode.init(SimpleNode.java:285) > at org.apache.velocity.Template.initDocument(Template.java:199) > at org.apache.velocity.Template.process(Template.java:121) > at > org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:415) > at > org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:335) > at > org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1102) > at > org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1077) > at > org.apache.velocity.app.VelocityEngine.getTemplate(VelocityEngine.java:528) > at > org.apache.velocity.tools.view.servlet.VelocityViewServlet.getTemplate(VelocityViewServlet.java:667) > at > org.apache.velocity.tools.view.servlet.VelocityViewServlet.handleRequest(VelocityViewServlet.java:601) > at > org.apache.velocity.tools.view.servlet.VelocityViewServlet.doRequest(VelocityViewServlet.java:541) > at > org.apache.velocity.tools.view.servlet.VelocityViewServlet.doGet(VelocityViewServlet.java:507) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) > at > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) > at > org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664) > at > org.apache.tomcat.util.net.PoolTcpEn
[jira] Commented: (VELOCITY-537) Multi-line comments causing ParseException in macros in Velocity engine 1.5
[ https://issues.apache.org/jira/browse/VELOCITY-537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12571167#action_12571167 ] Marnix van Bochove commented on VELOCITY-537: - I used this template to produce the problem: #macro(someMacro ) #* *# #end #someMacro() I use velocity to produce a application which consists of 385 generated java files. With the patch the resulting formatted java code produced by Velocity 4 is the same as produced by Velocity 5 (with patch). What's the best way to proof this patch for the project? I could make a unit test which fails without the patch and succeeds with the patch. > Multi-line comments causing ParseException in macros in Velocity engine 1.5 > --- > > Key: VELOCITY-537 > URL: https://issues.apache.org/jira/browse/VELOCITY-537 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 1.5 >Reporter: Christopher Townson > Fix For: 1.5.1 > > > Moving from velocity engine 1.4 to 1.5, one of my macros is now causing a > ParseException: > #macro( makeLink $filepath )#* > *##if ($request.serverName.equalsIgnoreCase("www.liveserver.com") || > $request.serverName.equalsIgnoreCase("liveserver.com"))#* > *##set($mirrorDomain = "livemirror.com")#* > *##elseif($request.serverName.equalsIgnoreCase("stagingserver.com"))#* > *##set($mirrorDomain = "stagingmirror.com")#* > *##elseif($request.serverName.equalsIgnoreCase("devserver.com") || > $request.serverName.equalsIgnoreCase("localhost"))#* > *##set($mirrorDomain = "devmirror.com")#* > *##else#* > *##set($mirrorDomain = "liveserver.com")#* > *##end#* > *#http://${mirrorDomain}${filepath}#* > *##end > This macro uses the mutli-line comment hack to gobble whitespace (so that > none appears in the link text, whilst preserving some kind of readability. > This works fine in 1.4, but throws a ParseException in 1.5 (stacktrace below) > -- stacktrace -- > 2007-04-03 16:05:38,712 - VelocimacroManager.parseTree() : exception makeLink > org.apache.velocity.runtime.parser.ParseException: Lexical error: > org.apache.velocity.runtime.parser.TokenMgrError: Lexical error at line 1, > column 535. Encountered: after : "" > at org.apache.velocity.runtime.parser.Parser.parse(Parser.java:124) > at > org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:1042) > at > org.apache.velocity.runtime.directive.VelocimacroProxy.parseTree(VelocimacroProxy.java:342) > at > org.apache.velocity.runtime.directive.VelocimacroProxy.setupMacro(VelocimacroProxy.java:322) > at > org.apache.velocity.runtime.directive.VelocimacroProxy.init(VelocimacroProxy.java:309) > at > org.apache.velocity.runtime.parser.node.ASTDirective.init(ASTDirective.java:134) > at > org.apache.velocity.runtime.parser.node.SimpleNode.init(SimpleNode.java:285) > at org.apache.velocity.Template.initDocument(Template.java:199) > at org.apache.velocity.Template.process(Template.java:121) > at > org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:415) > at > org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:335) > at > org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1102) > at > org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1077) > at > org.apache.velocity.app.VelocityEngine.getTemplate(VelocityEngine.java:528) > at > org.apache.velocity.tools.view.servlet.VelocityViewServlet.getTemplate(VelocityViewServlet.java:667) > at > org.apache.velocity.tools.view.servlet.VelocityViewServlet.handleRequest(VelocityViewServlet.java:601) > at > org.apache.velocity.tools.view.servlet.VelocityViewServlet.doRequest(VelocityViewServlet.java:541) > at > org.apache.velocity.tools.view.servlet.VelocityViewServlet.doGet(VelocityViewServlet.java:507) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) > at > org.
Re: Call a velocity macro
Geir and Nathan, Nathan Bubna wrote: Yeah, sorry. I forget about that, since i've been avoiding macros for some time and never actually bothered with this property: velocimacro.context.localscope = true I think that has further implications that what I was suggesting, which is a scope that inherits from the global (or outer) scope, rather than a completely separate, private scope. IIRC, localscope=true means that anything you want to get from the outer scope must be passed-in as a parameter to the macro (which wouldn't be all that bad, honestly). -chris signature.asc Description: OpenPGP digital signature
[jira] Updated: (VELOCITY-537) Multi-line comments causing ParseException in macros in Velocity engine 1.5
[ https://issues.apache.org/jira/browse/VELOCITY-537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marnix van Bochove updated VELOCITY-537: Attachment: velocity-537.zip I created a unit test. Extract the attached zip file to the root folder of velocity. Run ant to verify the build fails due to "Test org.apache.velocity.test.issues.Velocity537TestCase". Apply this patch to file src\java\org\apache\velocity\runtime\parser\node\NodeUtils.java : public static String tokenLiteral( Token t ) { String result; // Issue: VELOCITY-580 // Marnix 2008-02-20: Look at kind of token and return "" when it's a multiline comment if (t.kind == ParserConstants.MULTI_LINE_COMMENT) { result = ""; } else { result = specialText( t ) + t.image; } return result; } Run ant clean test and check if test succeeds. > Multi-line comments causing ParseException in macros in Velocity engine 1.5 > --- > > Key: VELOCITY-537 > URL: https://issues.apache.org/jira/browse/VELOCITY-537 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 1.5 >Reporter: Christopher Townson > Fix For: 1.5.1 > > Attachments: velocity-537.zip > > > Moving from velocity engine 1.4 to 1.5, one of my macros is now causing a > ParseException: > #macro( makeLink $filepath )#* > *##if ($request.serverName.equalsIgnoreCase("www.liveserver.com") || > $request.serverName.equalsIgnoreCase("liveserver.com"))#* > *##set($mirrorDomain = "livemirror.com")#* > *##elseif($request.serverName.equalsIgnoreCase("stagingserver.com"))#* > *##set($mirrorDomain = "stagingmirror.com")#* > *##elseif($request.serverName.equalsIgnoreCase("devserver.com") || > $request.serverName.equalsIgnoreCase("localhost"))#* > *##set($mirrorDomain = "devmirror.com")#* > *##else#* > *##set($mirrorDomain = "liveserver.com")#* > *##end#* > *#http://${mirrorDomain}${filepath}#* > *##end > This macro uses the mutli-line comment hack to gobble whitespace (so that > none appears in the link text, whilst preserving some kind of readability. > This works fine in 1.4, but throws a ParseException in 1.5 (stacktrace below) > -- stacktrace -- > 2007-04-03 16:05:38,712 - VelocimacroManager.parseTree() : exception makeLink > org.apache.velocity.runtime.parser.ParseException: Lexical error: > org.apache.velocity.runtime.parser.TokenMgrError: Lexical error at line 1, > column 535. Encountered: after : "" > at org.apache.velocity.runtime.parser.Parser.parse(Parser.java:124) > at > org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:1042) > at > org.apache.velocity.runtime.directive.VelocimacroProxy.parseTree(VelocimacroProxy.java:342) > at > org.apache.velocity.runtime.directive.VelocimacroProxy.setupMacro(VelocimacroProxy.java:322) > at > org.apache.velocity.runtime.directive.VelocimacroProxy.init(VelocimacroProxy.java:309) > at > org.apache.velocity.runtime.parser.node.ASTDirective.init(ASTDirective.java:134) > at > org.apache.velocity.runtime.parser.node.SimpleNode.init(SimpleNode.java:285) > at org.apache.velocity.Template.initDocument(Template.java:199) > at org.apache.velocity.Template.process(Template.java:121) > at > org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:415) > at > org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:335) > at > org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1102) > at > org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1077) > at > org.apache.velocity.app.VelocityEngine.getTemplate(VelocityEngine.java:528) > at > org.apache.velocity.tools.view.servlet.VelocityViewServlet.getTemplate(VelocityViewServlet.java:667) > at > org.apache.velocity.tools.view.servlet.VelocityViewServlet.handleRequest(VelocityViewServlet.java:601) > at > org.apache.velocity.tools.view.servlet.VelocityViewServlet.doRequest(VelocityViewServlet.java:541) > at > org.apache.velocity.tools.view.servlet.VelocityViewServlet.doGet(VelocityViewServlet.java:507) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) > at > org.apache.c
[jira] Commented: (VELOCITY-537) Multi-line comments causing ParseException in macros in Velocity engine 1.5
[ https://issues.apache.org/jira/browse/VELOCITY-537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12571230#action_12571230 ] Nathan Bubna commented on VELOCITY-537: --- Ah, so this is really a test for VELOCITY-580. I'm not seeing any parse exceptions, just an extra *# in the output. I suppose that makes sense since NodeUtils doesn't have to do with parsing :). I see your original patch comment refers to 580, not 537; i clearly wasn't paying sufficient attention earlier. I'll rename the test case to match.Anyway, it's great to have either dealt with, even if it's just a workaround. I'll probably hold off on committing the code for now, in hopes someone addresses the root cause and this won't be necessary. Thanks, this certainly resolves 580 nicely! > Multi-line comments causing ParseException in macros in Velocity engine 1.5 > --- > > Key: VELOCITY-537 > URL: https://issues.apache.org/jira/browse/VELOCITY-537 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 1.5 >Reporter: Christopher Townson > Fix For: 1.5.1 > > Attachments: velocity-537.zip > > > Moving from velocity engine 1.4 to 1.5, one of my macros is now causing a > ParseException: > #macro( makeLink $filepath )#* > *##if ($request.serverName.equalsIgnoreCase("www.liveserver.com") || > $request.serverName.equalsIgnoreCase("liveserver.com"))#* > *##set($mirrorDomain = "livemirror.com")#* > *##elseif($request.serverName.equalsIgnoreCase("stagingserver.com"))#* > *##set($mirrorDomain = "stagingmirror.com")#* > *##elseif($request.serverName.equalsIgnoreCase("devserver.com") || > $request.serverName.equalsIgnoreCase("localhost"))#* > *##set($mirrorDomain = "devmirror.com")#* > *##else#* > *##set($mirrorDomain = "liveserver.com")#* > *##end#* > *#http://${mirrorDomain}${filepath}#* > *##end > This macro uses the mutli-line comment hack to gobble whitespace (so that > none appears in the link text, whilst preserving some kind of readability. > This works fine in 1.4, but throws a ParseException in 1.5 (stacktrace below) > -- stacktrace -- > 2007-04-03 16:05:38,712 - VelocimacroManager.parseTree() : exception makeLink > org.apache.velocity.runtime.parser.ParseException: Lexical error: > org.apache.velocity.runtime.parser.TokenMgrError: Lexical error at line 1, > column 535. Encountered: after : "" > at org.apache.velocity.runtime.parser.Parser.parse(Parser.java:124) > at > org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:1042) > at > org.apache.velocity.runtime.directive.VelocimacroProxy.parseTree(VelocimacroProxy.java:342) > at > org.apache.velocity.runtime.directive.VelocimacroProxy.setupMacro(VelocimacroProxy.java:322) > at > org.apache.velocity.runtime.directive.VelocimacroProxy.init(VelocimacroProxy.java:309) > at > org.apache.velocity.runtime.parser.node.ASTDirective.init(ASTDirective.java:134) > at > org.apache.velocity.runtime.parser.node.SimpleNode.init(SimpleNode.java:285) > at org.apache.velocity.Template.initDocument(Template.java:199) > at org.apache.velocity.Template.process(Template.java:121) > at > org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:415) > at > org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:335) > at > org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1102) > at > org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1077) > at > org.apache.velocity.app.VelocityEngine.getTemplate(VelocityEngine.java:528) > at > org.apache.velocity.tools.view.servlet.VelocityViewServlet.getTemplate(VelocityViewServlet.java:667) > at > org.apache.velocity.tools.view.servlet.VelocityViewServlet.handleRequest(VelocityViewServlet.java:601) > at > org.apache.velocity.tools.view.servlet.VelocityViewServlet.doRequest(VelocityViewServlet.java:541) > at > org.apache.velocity.tools.view.servlet.VelocityViewServlet.doGet(VelocityViewServlet.java:507) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) > at >
[jira] Commented: (VELOCITY-580) Multi line comments simply don't work inside a macro
[ https://issues.apache.org/jira/browse/VELOCITY-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12571231#action_12571231 ] Nathan Bubna commented on VELOCITY-580: --- Marnix van Bochove posted a nice workaround patch that fixes this particular symptom in case VELOCITY-537. If no one comes up with a patch to fix the root problem, then i'll commit that patch to fix this before the next release. > Multi line comments simply don't work inside a macro > > > Key: VELOCITY-580 > URL: https://issues.apache.org/jira/browse/VELOCITY-580 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 1.5 >Reporter: BoD > > This very simple macro: > #macro(tabSection_begin $sectionTitle) > a > #* > test > *# > b > #end > produces : > a *# b > (notice the presence of the end of comment "*#" in the result !) > This worked as intended in 1.3.1. -- 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]