[jira] Commented: (VELOCITY-537) Multi-line comments causing ParseException in macros in Velocity engine 1.5

2008-02-21 Thread Marnix van Bochove (JIRA) 

[ 
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

2008-02-21 Thread Christopher Schultz 

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

2008-02-21 Thread Christopher Schultz (JIRA) 

[ 
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

2008-02-21 Thread Marnix van Bochove (JIRA) 

[ 
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

2008-02-21 Thread Nathan Bubna 
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

2008-02-21 Thread Geir Magnusson Jr. 

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

2008-02-21 Thread Nathan Bubna 
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

2008-02-21 Thread Nathan Bubna (JIRA) 

[ 
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

2008-02-21 Thread Nathan Bubna (JIRA) 

[ 
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

2008-02-21 Thread Marnix van Bochove (JIRA) 

[ 
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

2008-02-21 Thread Christopher Schultz 

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

2008-02-21 Thread Marnix van Bochove (JIRA) 

 [ 
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

2008-02-21 Thread Nathan Bubna (JIRA) 

[ 
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

2008-02-21 Thread Nathan Bubna (JIRA) 

[ 
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]