[jira] Created: (VELTOOLS-78) I get a UnsupportedClassVersionError: org/apache/velocity/tools/generic/DateTool (Unsupported major.minor version 49.0). But Velocity should run on Java 1.4???

[JIRA]

I get a UnsupportedClassVersionError: 
org/apache/velocity/tools/generic/DateTool (Unsupported major.minor version 
49.0). But Velocity should run on Java 1.4???
---

 Key: VELTOOLS-78
 URL: https://issues.apache.org/jira/browse/VELTOOLS-78
 Project: Velocity Tools
  Issue Type: Bug
  Components: GenericTools
Affects Versions: 1.3
 Environment: Tomcat 5.x, JDK 142_04, Windows NT
Reporter: Jon Are Storløkken


I got this problem when running on Tomcat 5 with JDK 142_04. As I understand, 
the new version of Velocity should still work on JDK 1.4. I guess it must have 
been compiled on Java 5...

java.lang.UnsupportedClassVersionError: 
org/apache/velocity/tools/generic/DateTool (Unsupported major.minor version 
49.0)
at java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:537)
at 
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:251)
at java.net.URLClassLoader.access$100(URLClassLoader.java:55)
at java.net.URLClassLoader$1.run(URLClassLoader.java:194)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
at 
org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:874)
at 
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1307)
at 
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1189)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
at java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:537)
at 
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:251)
at java.net.URLClassLoader.access$100(URLClassLoader.java:55)
at java.net.URLClassLoader$1.run(URLClassLoader.java:194)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
at 
org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:874)
at 
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1307)
at 
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1189)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
at 
org.springframework.web.servlet.view.velocity.VelocityView.exposeToolAttributes(VelocityView.java:454)
at 
org.springframework.web.servlet.view.velocity.VelocityView.renderMergedTemplateModel(VelocityView.java:321)
at 
org.springframework.web.servlet.view.AbstractTemplateView.renderMergedOutputModel(AbstractTemplateView.java:160)
at 
org.springframework.web.servlet.view.AbstractView.render(AbstractView.java:250)
at 
org.springframework.web.servlet.DispatcherServlet.render(DispatcherServlet.java:965)
at 
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:744)
at 
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:663)
at 
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:394)
at 
org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:348)
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:237)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214)
at 
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at 
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at 
org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152)
at 
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at 
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
at 
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at

[jira] Created: (VELOCITY-553) Posibility to configure ReportInvalidReferences to don't report report variables,properties and method which exist, but only have null value

[JIRA]

Posibility to configure ReportInvalidReferences to don't report report 
variables,properties and method which exist, but only have null value


 Key: VELOCITY-553
 URL: https://issues.apache.org/jira/browse/VELOCITY-553
 Project: Velocity
  Issue Type: Improvement
  Components: Engine
Affects Versions: 1.5
 Environment: any
Reporter: Tomáš Procházka


ReportInvalidReferences has very big imperfection, it report by default all 
variables, properties and method which has null value.
This may cause many problems for developer.

I for example need only validate template without any data, only check which 
contain right variables, properties or method (which exist), it's value is not 
important for me.

I tried use my own ReferenceInsertionEventHandler for replace null value with 
"" (empty String) but Velocity call InvalidReference handler before 
ReferenceInsertionEventHandler.

I suggest configuration options for this (repor or doesn't report null value)

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

[jira] Created: (VELOCITY-598) Macros within macros are losing the context

[JIRA]

Macros within macros are losing the context
---

 Key: VELOCITY-598
 URL: https://issues.apache.org/jira/browse/VELOCITY-598
 Project: Velocity
  Issue Type: Bug
  Components: Engine
Affects Versions: 1.5
 Environment: velocimacro.permissions.allow.inline.local.scope=true
velocimacro.permissions.allow.inline=true
velocimacro.context.localscope=false
(we can not change this!)
Reporter: Jörg Gottschling
Priority: Critical


consider the following test code:

#foreach($num in [1, 2, 3])
from loop body: $num
#macro(numMacro)$num (numMacro)#end
From Macro: #numMacro()
#end

it produces correctly:

from loop body: 1
>From Macro: 1 (numMacro)
from loop body: 2
>From Macro: 2 (numMacro)
from loop body: 3
>From Macro: 3 (numMacro)



But if you wrap this in a macro again, it fails:

#macro(outerMacro)
#foreach($num in [1, 2, 3])
from loop body: $num
#macro(numMacro)$num (numMacro)#end
From Macro: #numMacro()
#end
#end
#outerMacro()

output:

from loop body: 1
>From Macro: $num (numMacro)
from loop body: 2
>From Macro: $num (numMacro)
from loop body: 3
>From Macro: $num (numMacro)

That seams to be a bug for me, when considereing the settings above.

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

[jira] Created: (VELOCITY-605) Velocity tools / Message Tool - ambiguous method invocation with latest SVN head (1.6)

[JIRA]

Velocity tools / Message Tool - ambiguous method invocation with latest SVN 
head (1.6)
--

 Key: VELOCITY-605
 URL: https://issues.apache.org/jira/browse/VELOCITY-605
 Project: Velocity
  Issue Type: Bug
  Components: Engine
Affects Versions: 1.6
Reporter: Jarkko Viinamäki


I compiled the latest SVN head of Velocity today. Template memory consumption 
has gone down a lot. Great work!

However, I noticed that i18n string in my templates don't work anymore.

I have a properties file with:
toolbar.loggedin=Logged in as {0}

in the toolbox.xml:

  
 msg
 request
 
   org.apache.velocity.tools.struts.MessageTool
 
  


In the template file I have a string:
$msg.toolbar.loggedin.insert("joe")

This works with Velocity 1.5 and Velocity tools 1.4 fine but with latest SVN 
head build the velocity.log shows:

Introspection Error : Ambiguous method invocation insert(java.lang.String) for 
class class org.apache.velocity.tools.struts.MessageTool$TextKey

and the message isn't rendered at all.

Any idea what's wrong?

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

[jira] Created: (VELOCITY-606) Velocity 1.5 performance bottlenecks

[JIRA]

Velocity 1.5 performance bottlenecks


 Key: VELOCITY-606
 URL: https://issues.apache.org/jira/browse/VELOCITY-606
 Project: Velocity
  Issue Type: Bug
  Components: Engine
Affects Versions: 1.5
 Environment: Win XP, 1 Gb, single core, Maven 2, JUnitPerf, JRat, 
cached Velocity templates with a ClassLoader
Reporter: Jarkko Viinamäki


I did some quite extensive profiling to identify performance bottlenecks in 
Velocity 1.5.

Using Maven 2, JUnitPerf and JRat I was able to identify these methods as top 
bottlenecks:

org.apache.velocity.util.introspection  ClassMap - findMethod(String,Object[])
org.apache.velocity.util.introspection  IntrospectorBase - 
getMethod(Class,String,Object[])
org.apache.velocity.runtime.parser.node SimpleNode - literal()
org.apache.velocity.runtime.parser.node SimpleNode - 
render(InternalContextAdapter,Writer)
org.apache.commons.collections  ExtendedProperties - getBoolean(String,boolean)
org.apache.velocity.runtime.parser.node ASTReference - 
render(InternalContextAdapter,Writer)

The first two eat over 50% of the CPU with many threads. See attached 
screenshots.

Interestingly enough the synchronized
org.apache.velocity.runtime RuntimeInstance getTemplate(String,String)

isn't a big problem when templates are cached. However, if all resources are 
not cached it becomes a serious performance bottleneck. ResourceCacheImpl also 
uses a synchronized map which slows things down.

I think these bottlenecks could be at least made less worse by reducing 
synchronization by using ConcurrentHashMap and StringBuilder that ship with JDK 
1.5. I'm investigating what kind of benefits could be achieved with those.

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

[jira] Updated: (VELOCITY-606) Velocity 1.5 performance bottlenecks

[JIRA]

 [ 
https://issues.apache.org/jira/browse/VELOCITY-606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarkko Viinamäki updated VELOCITY-606:
--

Attachment: velocity-1.5-250-threads-loadtest.PNG

> Velocity 1.5 performance bottlenecks
> 
>
> Key: VELOCITY-606
> URL: https://issues.apache.org/jira/browse/VELOCITY-606
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
>Affects Versions: 1.5
> Environment: Win XP, 1 Gb, single core, Maven 2, JUnitPerf, JRat, 
> cached Velocity templates with a ClassLoader
>Reporter: Jarkko Viinamäki
> Attachments: velocity-1.5-250-threads-loadtest.PNG, 
> velocity-1.5-50-threads-loadtest.PNG
>
>
> I did some quite extensive profiling to identify performance bottlenecks in 
> Velocity 1.5.
> Using Maven 2, JUnitPerf and JRat I was able to identify these methods as top 
> bottlenecks:
> org.apache.velocity.util.introspectionClassMap - 
> findMethod(String,Object[])
> org.apache.velocity.util.introspectionIntrospectorBase - 
> getMethod(Class,String,Object[])
> org.apache.velocity.runtime.parser.node   SimpleNode - literal()
> org.apache.velocity.runtime.parser.node   SimpleNode - 
> render(InternalContextAdapter,Writer)
> org.apache.commons.collectionsExtendedProperties - 
> getBoolean(String,boolean)
> org.apache.velocity.runtime.parser.node   ASTReference - 
> render(InternalContextAdapter,Writer)
> The first two eat over 50% of the CPU with many threads. See attached 
> screenshots.
> Interestingly enough the synchronized
> org.apache.velocity.runtime   RuntimeInstance getTemplate(String,String)
> isn't a big problem when templates are cached. However, if all resources are 
> not cached it becomes a serious performance bottleneck. ResourceCacheImpl 
> also uses a synchronized map which slows things down.
> I think these bottlenecks could be at least made less worse by reducing 
> synchronization by using ConcurrentHashMap and StringBuilder that ship with 
> JDK 1.5. I'm investigating what kind of benefits could be achieved with those.

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

[jira] Updated: (VELOCITY-606) Velocity 1.5 performance bottlenecks

[JIRA]

 [ 
https://issues.apache.org/jira/browse/VELOCITY-606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarkko Viinamäki updated VELOCITY-606:
--

Attachment: velocity-1.5-50-threads-loadtest.PNG

> Velocity 1.5 performance bottlenecks
> 
>
> Key: VELOCITY-606
> URL: https://issues.apache.org/jira/browse/VELOCITY-606
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
>Affects Versions: 1.5
> Environment: Win XP, 1 Gb, single core, Maven 2, JUnitPerf, JRat, 
> cached Velocity templates with a ClassLoader
>Reporter: Jarkko Viinamäki
> Attachments: velocity-1.5-250-threads-loadtest.PNG, 
> velocity-1.5-50-threads-loadtest.PNG
>
>
> I did some quite extensive profiling to identify performance bottlenecks in 
> Velocity 1.5.
> Using Maven 2, JUnitPerf and JRat I was able to identify these methods as top 
> bottlenecks:
> org.apache.velocity.util.introspectionClassMap - 
> findMethod(String,Object[])
> org.apache.velocity.util.introspectionIntrospectorBase - 
> getMethod(Class,String,Object[])
> org.apache.velocity.runtime.parser.node   SimpleNode - literal()
> org.apache.velocity.runtime.parser.node   SimpleNode - 
> render(InternalContextAdapter,Writer)
> org.apache.commons.collectionsExtendedProperties - 
> getBoolean(String,boolean)
> org.apache.velocity.runtime.parser.node   ASTReference - 
> render(InternalContextAdapter,Writer)
> The first two eat over 50% of the CPU with many threads. See attached 
> screenshots.
> Interestingly enough the synchronized
> org.apache.velocity.runtime   RuntimeInstance getTemplate(String,String)
> isn't a big problem when templates are cached. However, if all resources are 
> not cached it becomes a serious performance bottleneck. ResourceCacheImpl 
> also uses a synchronized map which slows things down.
> I think these bottlenecks could be at least made less worse by reducing 
> synchronization by using ConcurrentHashMap and StringBuilder that ship with 
> JDK 1.5. I'm investigating what kind of benefits could be achieved with those.

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

[jira] Commented: (VELOCITY-606) Velocity 1.5 performance bottlenecks

[JIRA]

[ 
https://issues.apache.org/jira/browse/VELOCITY-606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616051#action_12616051
 ] 

Jarkko Viinamäki commented on VELOCITY-606:
---

I made some modifications using java.util.concurrent and some small tricks to 
optimize the code. In my tests (which uses macros and most of the velocity 
directives) I was able to get over 20% performance boost. 

Although all tests pass and I was able to run Velocity app on Jetty with quite 
high load (70 concurrent users constantly bombarding with 0 delay) and I didn't 
see any errors, there can certainly be concurrency problems, race conditions 
and all that nasty stuff in my modifications. Feel free to laugh at my 
incompetence. :)

Modified jar, patch and screenshots are here:
http://www.iki.fi/wyla/velocity/

I'll also include them as attachment.

---

Regarding ConcurrentHashMap: if I'm not mistaken, there was some fix in the 
Java memory model in JDK 1.5 so there might be some problems with the 
backported version. Also licensing issues regarding that are a bit unclear. 
Further JDK 1.6 is faster than 1.5 and 1.5 is faster than 1.4 so I wouldn't use 
an old version in production.

> Velocity 1.5 performance bottlenecks
> 
>
> Key: VELOCITY-606
> URL: https://issues.apache.org/jira/browse/VELOCITY-606
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
>Affects Versions: 1.5
> Environment: Win XP, 1 Gb, single core, Maven 2, JUnitPerf, JRat, 
> cached Velocity templates with a ClassLoader
>Reporter: Jarkko Viinamäki
> Attachments: velocity-1.5-250-threads-loadtest.PNG, 
> velocity-1.5-50-threads-loadtest.PNG, VELOCITY-606-light.patch, 
> VELOCITY-606.patch
>
>
> I did some quite extensive profiling to identify performance bottlenecks in 
> Velocity 1.5.
> Using Maven 2, JUnitPerf and JRat I was able to identify these methods as top 
> bottlenecks:
> org.apache.velocity.util.introspectionClassMap - 
> findMethod(String,Object[])
> org.apache.velocity.util.introspectionIntrospectorBase - 
> getMethod(Class,String,Object[])
> org.apache.velocity.runtime.parser.node   SimpleNode - literal()
> org.apache.velocity.runtime.parser.node   SimpleNode - 
> render(InternalContextAdapter,Writer)
> org.apache.commons.collectionsExtendedProperties - 
> getBoolean(String,boolean)
> org.apache.velocity.runtime.parser.node   ASTReference - 
> render(InternalContextAdapter,Writer)
> The first two eat over 50% of the CPU with many threads. See attached 
> screenshots.
> Interestingly enough the synchronized
> org.apache.velocity.runtime   RuntimeInstance getTemplate(String,String)
> isn't a big problem when templates are cached. However, if all resources are 
> not cached it becomes a serious performance bottleneck. ResourceCacheImpl 
> also uses a synchronized map which slows things down.
> I think these bottlenecks could be at least made less worse by reducing 
> synchronization by using ConcurrentHashMap and StringBuilder that ship with 
> JDK 1.5. I'm investigating what kind of benefits could be achieved with those.

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

[jira] Updated: (VELOCITY-606) Velocity 1.5 performance bottlenecks

[JIRA]

 [ 
https://issues.apache.org/jira/browse/VELOCITY-606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarkko Viinamäki updated VELOCITY-606:
--

Attachment: velocity-1.6-dev-concurrentmods.patch

Lots of small modifications to improve performance. Thread-safety and locking 
issues may exist and have not been fully verified.

> Velocity 1.5 performance bottlenecks
> 
>
> Key: VELOCITY-606
> URL: https://issues.apache.org/jira/browse/VELOCITY-606
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
>Affects Versions: 1.5
> Environment: Win XP, 1 Gb, single core, Maven 2, JUnitPerf, JRat, 
> cached Velocity templates with a ClassLoader
>Reporter: Jarkko Viinamäki
> Attachments: velocity-1.5-250-threads-loadtest.PNG, 
> velocity-1.5-50-threads-loadtest.PNG, velocity-1.6-dev-concurrentmods.patch, 
> velocity-1.6-dev-concurrentpatch-250-threads-loadtest.PNG, 
> VELOCITY-606-light.patch, VELOCITY-606.patch
>
>
> I did some quite extensive profiling to identify performance bottlenecks in 
> Velocity 1.5.
> Using Maven 2, JUnitPerf and JRat I was able to identify these methods as top 
> bottlenecks:
> org.apache.velocity.util.introspectionClassMap - 
> findMethod(String,Object[])
> org.apache.velocity.util.introspectionIntrospectorBase - 
> getMethod(Class,String,Object[])
> org.apache.velocity.runtime.parser.node   SimpleNode - literal()
> org.apache.velocity.runtime.parser.node   SimpleNode - 
> render(InternalContextAdapter,Writer)
> org.apache.commons.collectionsExtendedProperties - 
> getBoolean(String,boolean)
> org.apache.velocity.runtime.parser.node   ASTReference - 
> render(InternalContextAdapter,Writer)
> The first two eat over 50% of the CPU with many threads. See attached 
> screenshots.
> Interestingly enough the synchronized
> org.apache.velocity.runtime   RuntimeInstance getTemplate(String,String)
> isn't a big problem when templates are cached. However, if all resources are 
> not cached it becomes a serious performance bottleneck. ResourceCacheImpl 
> also uses a synchronized map which slows things down.
> I think these bottlenecks could be at least made less worse by reducing 
> synchronization by using ConcurrentHashMap and StringBuilder that ship with 
> JDK 1.5. I'm investigating what kind of benefits could be achieved with those.

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

[jira] Updated: (VELOCITY-606) Velocity 1.5 performance bottlenecks

[JIRA]

 [ 
https://issues.apache.org/jira/browse/VELOCITY-606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarkko Viinamäki updated VELOCITY-606:
--

Attachment: velocity-1.6-dev-concurrentpatch-250-threads-loadtest.PNG

JRat profiling screenshot after modifications.

> Velocity 1.5 performance bottlenecks
> 
>
> Key: VELOCITY-606
> URL: https://issues.apache.org/jira/browse/VELOCITY-606
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
>Affects Versions: 1.5
> Environment: Win XP, 1 Gb, single core, Maven 2, JUnitPerf, JRat, 
> cached Velocity templates with a ClassLoader
>Reporter: Jarkko Viinamäki
> Attachments: velocity-1.5-250-threads-loadtest.PNG, 
> velocity-1.5-50-threads-loadtest.PNG, velocity-1.6-dev-concurrentmods.patch, 
> velocity-1.6-dev-concurrentpatch-250-threads-loadtest.PNG, 
> VELOCITY-606-light.patch, VELOCITY-606.patch
>
>
> I did some quite extensive profiling to identify performance bottlenecks in 
> Velocity 1.5.
> Using Maven 2, JUnitPerf and JRat I was able to identify these methods as top 
> bottlenecks:
> org.apache.velocity.util.introspectionClassMap - 
> findMethod(String,Object[])
> org.apache.velocity.util.introspectionIntrospectorBase - 
> getMethod(Class,String,Object[])
> org.apache.velocity.runtime.parser.node   SimpleNode - literal()
> org.apache.velocity.runtime.parser.node   SimpleNode - 
> render(InternalContextAdapter,Writer)
> org.apache.commons.collectionsExtendedProperties - 
> getBoolean(String,boolean)
> org.apache.velocity.runtime.parser.node   ASTReference - 
> render(InternalContextAdapter,Writer)
> The first two eat over 50% of the CPU with many threads. See attached 
> screenshots.
> Interestingly enough the synchronized
> org.apache.velocity.runtime   RuntimeInstance getTemplate(String,String)
> isn't a big problem when templates are cached. However, if all resources are 
> not cached it becomes a serious performance bottleneck. ResourceCacheImpl 
> also uses a synchronized map which slows things down.
> I think these bottlenecks could be at least made less worse by reducing 
> synchronization by using ConcurrentHashMap and StringBuilder that ship with 
> JDK 1.5. I'm investigating what kind of benefits could be achieved with those.

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

[jira] Commented: (VELOCITY-606) Velocity 1.5 performance bottlenecks

[JIRA]

[ 
https://issues.apache.org/jira/browse/VELOCITY-606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616157#action_12616157
 ] 

Jarkko Viinamäki commented on VELOCITY-606:
---

Thanks for your quick analysis and comments Nathan! Much appreciated.

Your patch seems elegant so I'll checkout the source, apply the patches and run 
my profiling tests with those.

> Velocity 1.5 performance bottlenecks
> 
>
> Key: VELOCITY-606
> URL: https://issues.apache.org/jira/browse/VELOCITY-606
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
>Affects Versions: 1.5
> Environment: Win XP, 1 Gb, single core, Maven 2, JUnitPerf, JRat, 
> cached Velocity templates with a ClassLoader
>Reporter: Jarkko Viinamäki
> Attachments: velocity-1.5-250-threads-loadtest.PNG, 
> velocity-1.5-50-threads-loadtest.PNG, velocity-1.6-dev-concurrentmods.patch, 
> velocity-1.6-dev-concurrentpatch-250-threads-loadtest.PNG, 
> VELOCITY-606-light.patch, VELOCITY-606.patch
>
>
> I did some quite extensive profiling to identify performance bottlenecks in 
> Velocity 1.5.
> Using Maven 2, JUnitPerf and JRat I was able to identify these methods as top 
> bottlenecks:
> org.apache.velocity.util.introspectionClassMap - 
> findMethod(String,Object[])
> org.apache.velocity.util.introspectionIntrospectorBase - 
> getMethod(Class,String,Object[])
> org.apache.velocity.runtime.parser.node   SimpleNode - literal()
> org.apache.velocity.runtime.parser.node   SimpleNode - 
> render(InternalContextAdapter,Writer)
> org.apache.commons.collectionsExtendedProperties - 
> getBoolean(String,boolean)
> org.apache.velocity.runtime.parser.node   ASTReference - 
> render(InternalContextAdapter,Writer)
> The first two eat over 50% of the CPU with many threads. See attached 
> screenshots.
> Interestingly enough the synchronized
> org.apache.velocity.runtime   RuntimeInstance getTemplate(String,String)
> isn't a big problem when templates are cached. However, if all resources are 
> not cached it becomes a serious performance bottleneck. ResourceCacheImpl 
> also uses a synchronized map which slows things down.
> I think these bottlenecks could be at least made less worse by reducing 
> synchronization by using ConcurrentHashMap and StringBuilder that ship with 
> JDK 1.5. I'm investigating what kind of benefits could be achieved with those.

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

[jira] Commented: (VELOCITY-606) Velocity 1.5 performance bottlenecks

[JIRA]

[ 
https://issues.apache.org/jira/browse/VELOCITY-606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616808#action_12616808
 ] 

Jarkko Viinamäki commented on VELOCITY-606:
---

OK. I did some profiling with latest SVN head (679708). I have some good news 
and bad news.

The good news is that the current head is slightly faster than 1.5 with some of 
my test templates. ClassMap.findMethod still seems to be a major bottleneck.

However, the bad news is that modifications made to the macro system in 1.6 
have made concurrent macro processing extremely slow and templates with many 
invocations to the same macro sometimes fail with 
"org.apache.velocity.exception.MacroOverflowException: Exceed maximum 20 macro 
calls. " when there are many concurrent threads. I'll file a separate issue 
about this.

My pathetic little testbench is available at: 
http://www.iki.fi/wyla/velocity/testbench (free to use)

With that it's relatively easy to run load tests and use JRat as profiler. 



> Velocity 1.5 performance bottlenecks
> 
>
> Key: VELOCITY-606
> URL: https://issues.apache.org/jira/browse/VELOCITY-606
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
>Affects Versions: 1.5
> Environment: Win XP, 1 Gb, single core, Maven 2, JUnitPerf, JRat, 
> cached Velocity templates with a ClassLoader
>Reporter: Jarkko Viinamäki
> Attachments: velocity-1.5-250-threads-loadtest.PNG, 
> velocity-1.5-50-threads-loadtest.PNG, velocity-1.6-dev-concurrentmods.patch, 
> velocity-1.6-dev-concurrentpatch-250-threads-loadtest.PNG, 
> velocity-1.6-head-20080725-test.vm.PNG, VELOCITY-606-light.patch, 
> VELOCITY-606.patch
>
>
> I did some quite extensive profiling to identify performance bottlenecks in 
> Velocity 1.5.
> Using Maven 2, JUnitPerf and JRat I was able to identify these methods as top 
> bottlenecks:
> org.apache.velocity.util.introspectionClassMap - 
> findMethod(String,Object[])
> org.apache.velocity.util.introspectionIntrospectorBase - 
> getMethod(Class,String,Object[])
> org.apache.velocity.runtime.parser.node   SimpleNode - literal()
> org.apache.velocity.runtime.parser.node   SimpleNode - 
> render(InternalContextAdapter,Writer)
> org.apache.commons.collectionsExtendedProperties - 
> getBoolean(String,boolean)
> org.apache.velocity.runtime.parser.node   ASTReference - 
> render(InternalContextAdapter,Writer)
> The first two eat over 50% of the CPU with many threads. See attached 
> screenshots.
> Interestingly enough the synchronized
> org.apache.velocity.runtime   RuntimeInstance getTemplate(String,String)
> isn't a big problem when templates are cached. However, if all resources are 
> not cached it becomes a serious performance bottleneck. ResourceCacheImpl 
> also uses a synchronized map which slows things down.
> I think these bottlenecks could be at least made less worse by reducing 
> synchronization by using ConcurrentHashMap and StringBuilder that ship with 
> JDK 1.5. I'm investigating what kind of benefits could be achieved with those.

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

[jira] Updated: (VELOCITY-606) Velocity 1.5 performance bottlenecks

[JIRA]

 [ 
https://issues.apache.org/jira/browse/VELOCITY-606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarkko Viinamäki updated VELOCITY-606:
--

Attachment: velocity-1.6-head-20080725-test.vm.PNG

JRat profiling results of SVN revision (679708) with test.vm (included in my 
testbench)

> Velocity 1.5 performance bottlenecks
> 
>
> Key: VELOCITY-606
> URL: https://issues.apache.org/jira/browse/VELOCITY-606
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
>Affects Versions: 1.5
> Environment: Win XP, 1 Gb, single core, Maven 2, JUnitPerf, JRat, 
> cached Velocity templates with a ClassLoader
>Reporter: Jarkko Viinamäki
> Attachments: velocity-1.5-250-threads-loadtest.PNG, 
> velocity-1.5-50-threads-loadtest.PNG, velocity-1.6-dev-concurrentmods.patch, 
> velocity-1.6-dev-concurrentpatch-250-threads-loadtest.PNG, 
> velocity-1.6-head-20080725-test.vm.PNG, VELOCITY-606-light.patch, 
> VELOCITY-606.patch
>
>
> I did some quite extensive profiling to identify performance bottlenecks in 
> Velocity 1.5.
> Using Maven 2, JUnitPerf and JRat I was able to identify these methods as top 
> bottlenecks:
> org.apache.velocity.util.introspectionClassMap - 
> findMethod(String,Object[])
> org.apache.velocity.util.introspectionIntrospectorBase - 
> getMethod(Class,String,Object[])
> org.apache.velocity.runtime.parser.node   SimpleNode - literal()
> org.apache.velocity.runtime.parser.node   SimpleNode - 
> render(InternalContextAdapter,Writer)
> org.apache.commons.collectionsExtendedProperties - 
> getBoolean(String,boolean)
> org.apache.velocity.runtime.parser.node   ASTReference - 
> render(InternalContextAdapter,Writer)
> The first two eat over 50% of the CPU with many threads. See attached 
> screenshots.
> Interestingly enough the synchronized
> org.apache.velocity.runtime   RuntimeInstance getTemplate(String,String)
> isn't a big problem when templates are cached. However, if all resources are 
> not cached it becomes a serious performance bottleneck. ResourceCacheImpl 
> also uses a synchronized map which slows things down.
> I think these bottlenecks could be at least made less worse by reducing 
> synchronization by using ConcurrentHashMap and StringBuilder that ship with 
> JDK 1.5. I'm investigating what kind of benefits could be achieved with those.

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

[jira] Updated: (VELOCITY-607) Runtime macro rendering very slow in Velocity 1.6-dev (679708) compared to 1.5

[JIRA]

 [ 
https://issues.apache.org/jira/browse/VELOCITY-607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarkko Viinamäki updated VELOCITY-607:
--

Attachment: velocity-1.6-head-20080725-velocity24-test.PNG

> Runtime macro rendering very slow in Velocity 1.6-dev (679708) compared to 1.5
> --
>
> Key: VELOCITY-607
> URL: https://issues.apache.org/jira/browse/VELOCITY-607
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
> Environment: Maven 2, JUnit, JUnitPerf, JRat, custom testbench: 
> http://www.iki.fi/wyla/velocity/testbench
>Reporter: Jarkko Viinamäki
>Priority: Critical
> Attachments: velocity-1.6-head-20080725-velocity24-test.PNG
>
>
> The following test template (see VELOCITY-24):
> ## local macro, not global
> #macro(letter $char)
> This is the letter $char
> #end
> #letter("A")
> #letter("B")
> #letter("C")
> #letter("D")
> #letter("E")
> #letter("F")
> #letter("G")
> #letter("H")
> #letter("I")
> #letter("J")
> #letter("K")
> #letter("L")
> #letter("M")
> #letter("N")
> #letter("O")
> #letter("P")
> #letter("Q")
> #letter("R")
> #letter("S")
> #letter("T")
> #letter("U")
> #letter("V")
> #letter("W")
> #letter("X")
> #letter("Y")
> #letter("Z")
> ---
> Works quickly and correctly with Velocity 1.5 with several concurrent 
> threads. However, 1.6-dev is a LOT slower (even 20x).
> The major performance bottlenecks seem to be:
> RuntimeMacro.render (60% of time)
> VelocimacroFactory.getVelocimacro (20% of time)
> With several threads this test also causes Velocity to throw error(s):
> org.apache.velocity.exception.MacroOverflowException: Exceed maximum 20 macro 
> calls. Call Stack:letter->letter->letter->letter->letter
>   at 
> org.apache.velocity.runtime.VelocimacroFactory.startMacroRendering(VelocimacroFactory.java:179)
>   at 
> org.apache.velocity.runtime.RuntimeInstance.startMacroRendering(RuntimeInstance.java:1693)
>   at 
> org.apache.velocity.runtime.directive.VelocimacroProxy.render(VelocimacroProxy.java:200)
>   at 
> org.apache.velocity.runtime.directive.RuntimeMacro.render(RuntimeMacro.java:230)
>   at 
> org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:178)
>   at 
> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:323)
>   at org.apache.velocity.Template.merge(Template.java:324)
>   at org.apache.velocity.Template.merge(Template.java:232)
>   at 
> org.apache.velocity.test.load.Velocity24Test.testRendering(Velocity24Test.java:51)
> This is related to VELOCITY-297 but the fix doesn't seem work with the new 
> modified macro implementation.

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

[jira] Created: (VELOCITY-607) Runtime macro rendering very slow in Velocity 1.6-dev (679708) compared to 1.5

[JIRA]

Runtime macro rendering very slow in Velocity 1.6-dev (679708) compared to 1.5
--

 Key: VELOCITY-607
 URL: https://issues.apache.org/jira/browse/VELOCITY-607
 Project: Velocity
  Issue Type: Bug
  Components: Engine
 Environment: Maven 2, JUnit, JUnitPerf, JRat, custom testbench: 
http://www.iki.fi/wyla/velocity/testbench
Reporter: Jarkko Viinamäki
Priority: Critical
 Attachments: velocity-1.6-head-20080725-velocity24-test.PNG

The following test template (see VELOCITY-24):

## local macro, not global
#macro(letter $char)
This is the letter $char
#end

#letter("A")
#letter("B")
#letter("C")
#letter("D")
#letter("E")
#letter("F")
#letter("G")
#letter("H")
#letter("I")
#letter("J")
#letter("K")
#letter("L")
#letter("M")
#letter("N")
#letter("O")
#letter("P")
#letter("Q")
#letter("R")
#letter("S")
#letter("T")
#letter("U")
#letter("V")
#letter("W")
#letter("X")
#letter("Y")
#letter("Z")

---

Works quickly and correctly with Velocity 1.5 with several concurrent threads. 
However, 1.6-dev is a LOT slower (even 20x).

The major performance bottlenecks seem to be:
RuntimeMacro.render (60% of time)
VelocimacroFactory.getVelocimacro (20% of time)

With several threads this test also causes Velocity to throw error(s):

org.apache.velocity.exception.MacroOverflowException: Exceed maximum 20 macro 
calls. Call Stack:letter->letter->letter->letter->letter
at 
org.apache.velocity.runtime.VelocimacroFactory.startMacroRendering(VelocimacroFactory.java:179)
at 
org.apache.velocity.runtime.RuntimeInstance.startMacroRendering(RuntimeInstance.java:1693)
at 
org.apache.velocity.runtime.directive.VelocimacroProxy.render(VelocimacroProxy.java:200)
at 
org.apache.velocity.runtime.directive.RuntimeMacro.render(RuntimeMacro.java:230)
at 
org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:178)
at 
org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:323)
at org.apache.velocity.Template.merge(Template.java:324)
at org.apache.velocity.Template.merge(Template.java:232)
at 
org.apache.velocity.test.load.Velocity24Test.testRendering(Velocity24Test.java:51)

This is related to VELOCITY-297 but the fix doesn't seem work with the new 
modified macro implementation.


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

[jira] Updated: (VELOCITY-607) Runtime macro rendering very slow in Velocity 1.6-dev (679708) compared to 1.5

[JIRA]

 [ 
https://issues.apache.org/jira/browse/VELOCITY-607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarkko Viinamäki updated VELOCITY-607:
--

Attachment: velocity-1.5-velocity24-test.PNG

> Runtime macro rendering very slow in Velocity 1.6-dev (679708) compared to 1.5
> --
>
> Key: VELOCITY-607
> URL: https://issues.apache.org/jira/browse/VELOCITY-607
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
> Environment: Maven 2, JUnit, JUnitPerf, JRat, custom testbench: 
> http://www.iki.fi/wyla/velocity/testbench
>Reporter: Jarkko Viinamäki
>Priority: Critical
> Attachments: velocity-1.5-velocity24-test.PNG, 
> velocity-1.6-head-20080725-velocity24-test.PNG
>
>
> The following test template (see VELOCITY-24):
> ## local macro, not global
> #macro(letter $char)
> This is the letter $char
> #end
> #letter("A")
> #letter("B")
> #letter("C")
> #letter("D")
> #letter("E")
> #letter("F")
> #letter("G")
> #letter("H")
> #letter("I")
> #letter("J")
> #letter("K")
> #letter("L")
> #letter("M")
> #letter("N")
> #letter("O")
> #letter("P")
> #letter("Q")
> #letter("R")
> #letter("S")
> #letter("T")
> #letter("U")
> #letter("V")
> #letter("W")
> #letter("X")
> #letter("Y")
> #letter("Z")
> ---
> Works quickly and correctly with Velocity 1.5 with several concurrent 
> threads. However, 1.6-dev is a LOT slower (even 20x).
> The major performance bottlenecks seem to be:
> RuntimeMacro.render (60% of time)
> VelocimacroFactory.getVelocimacro (20% of time)
> With several threads this test also causes Velocity to throw error(s):
> org.apache.velocity.exception.MacroOverflowException: Exceed maximum 20 macro 
> calls. Call Stack:letter->letter->letter->letter->letter
>   at 
> org.apache.velocity.runtime.VelocimacroFactory.startMacroRendering(VelocimacroFactory.java:179)
>   at 
> org.apache.velocity.runtime.RuntimeInstance.startMacroRendering(RuntimeInstance.java:1693)
>   at 
> org.apache.velocity.runtime.directive.VelocimacroProxy.render(VelocimacroProxy.java:200)
>   at 
> org.apache.velocity.runtime.directive.RuntimeMacro.render(RuntimeMacro.java:230)
>   at 
> org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:178)
>   at 
> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:323)
>   at org.apache.velocity.Template.merge(Template.java:324)
>   at org.apache.velocity.Template.merge(Template.java:232)
>   at 
> org.apache.velocity.test.load.Velocity24Test.testRendering(Velocity24Test.java:51)
> This is related to VELOCITY-297 but the fix doesn't seem work with the new 
> modified macro implementation.

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

[jira] Issue Comment Edited: (VELOCITY-606) Velocity 1.5 performance bottlenecks

[JIRA]

[ 
https://issues.apache.org/jira/browse/VELOCITY-606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616808#action_12616808
 ] 

wyla edited comment on VELOCITY-606 at 7/25/08 3:58 AM:


OK. I did some profiling with latest SVN head (679708). I have some good news 
and bad news.

The good news is that the current head is slightly faster than 1.5 with some of 
my test templates. InspectorBase.getMethod still seems to be a major bottleneck 
after applying patches 606 and 595.

However, the bad news is that modifications made to the macro system in 1.6 
have made concurrent macro processing extremely slow and templates with many 
invocations to the same macro sometimes fail with 
"org.apache.velocity.exception.MacroOverflowException: Exceed maximum 20 macro 
calls. " when there are many concurrent threads. I'll file a separate issue 
about this.

My pathetic little testbench is available at: 
http://www.iki.fi/wyla/velocity/testbench (free to use)

With that it's relatively easy to run load tests and use JRat as profiler. 



  was (Author: wyla):
OK. I did some profiling with latest SVN head (679708). I have some good 
news and bad news.

The good news is that the current head is slightly faster than 1.5 with some of 
my test templates. ClassMap.findMethod still seems to be a major bottleneck.

However, the bad news is that modifications made to the macro system in 1.6 
have made concurrent macro processing extremely slow and templates with many 
invocations to the same macro sometimes fail with 
"org.apache.velocity.exception.MacroOverflowException: Exceed maximum 20 macro 
calls. " when there are many concurrent threads. I'll file a separate issue 
about this.

My pathetic little testbench is available at: 
http://www.iki.fi/wyla/velocity/testbench (free to use)

With that it's relatively easy to run load tests and use JRat as profiler. 


  
> Velocity 1.5 performance bottlenecks
> 
>
> Key: VELOCITY-606
> URL: https://issues.apache.org/jira/browse/VELOCITY-606
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
>Affects Versions: 1.5
> Environment: Win XP, 1 Gb, single core, Maven 2, JUnitPerf, JRat, 
> cached Velocity templates with a ClassLoader
>Reporter: Jarkko Viinamäki
> Attachments: velocity-1.5-250-threads-loadtest.PNG, 
> velocity-1.5-50-threads-loadtest.PNG, velocity-1.6-dev-concurrentmods.patch, 
> velocity-1.6-dev-concurrentpatch-250-threads-loadtest.PNG, 
> velocity-1.6-head-20080725-test.vm.PNG, VELOCITY-606-light.patch, 
> VELOCITY-606.patch
>
>
> I did some quite extensive profiling to identify performance bottlenecks in 
> Velocity 1.5.
> Using Maven 2, JUnitPerf and JRat I was able to identify these methods as top 
> bottlenecks:
> org.apache.velocity.util.introspectionClassMap - 
> findMethod(String,Object[])
> org.apache.velocity.util.introspectionIntrospectorBase - 
> getMethod(Class,String,Object[])
> org.apache.velocity.runtime.parser.node   SimpleNode - literal()
> org.apache.velocity.runtime.parser.node   SimpleNode - 
> render(InternalContextAdapter,Writer)
> org.apache.commons.collectionsExtendedProperties - 
> getBoolean(String,boolean)
> org.apache.velocity.runtime.parser.node   ASTReference - 
> render(InternalContextAdapter,Writer)
> The first two eat over 50% of the CPU with many threads. See attached 
> screenshots.
> Interestingly enough the synchronized
> org.apache.velocity.runtime   RuntimeInstance getTemplate(String,String)
> isn't a big problem when templates are cached. However, if all resources are 
> not cached it becomes a serious performance bottleneck. ResourceCacheImpl 
> also uses a synchronized map which slows things down.
> I think these bottlenecks could be at least made less worse by reducing 
> synchronization by using ConcurrentHashMap and StringBuilder that ship with 
> JDK 1.5. I'm investigating what kind of benefits could be achieved with those.

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

[jira] Commented: (VELOCITY-607) Runtime macro rendering very slow in Velocity 1.6-dev (679708) compared to 1.5

[JIRA]

[ 
https://issues.apache.org/jira/browse/VELOCITY-607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616936#action_12616936
 ] 

Jarkko Viinamäki commented on VELOCITY-607:
---

Also I think that it would be nice if one could switch that recursive call 
tracking off in the configuration file since it's quite expensive to do (there 
are some tough synchronized blocks).




> Runtime macro rendering very slow in Velocity 1.6-dev (679708) compared to 1.5
> --
>
> Key: VELOCITY-607
> URL: https://issues.apache.org/jira/browse/VELOCITY-607
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
> Environment: Maven 2, JUnit, JUnitPerf, JRat, custom testbench: 
> http://www.iki.fi/wyla/velocity/testbench
>Reporter: Jarkko Viinamäki
>Assignee: Nathan Bubna
>Priority: Critical
> Attachments: velocity-1.5-velocity24-test.PNG, 
> velocity-1.6-head-20080725-velocity24-test.PNG
>
>
> The following test template (see VELOCITY-24):
> ## local macro, not global
> #macro(letter $char)
> This is the letter $char
> #end
> #letter("A")
> #letter("B")
> #letter("C")
> #letter("D")
> #letter("E")
> #letter("F")
> #letter("G")
> #letter("H")
> #letter("I")
> #letter("J")
> #letter("K")
> #letter("L")
> #letter("M")
> #letter("N")
> #letter("O")
> #letter("P")
> #letter("Q")
> #letter("R")
> #letter("S")
> #letter("T")
> #letter("U")
> #letter("V")
> #letter("W")
> #letter("X")
> #letter("Y")
> #letter("Z")
> ---
> Works quickly and correctly with Velocity 1.5 with several concurrent 
> threads. However, 1.6-dev is a LOT slower (even 20x).
> The major performance bottlenecks seem to be:
> RuntimeMacro.render (60% of time)
> VelocimacroFactory.getVelocimacro (20% of time)
> With several threads this test also causes Velocity to throw error(s):
> org.apache.velocity.exception.MacroOverflowException: Exceed maximum 20 macro 
> calls. Call Stack:letter->letter->letter->letter->letter
>   at 
> org.apache.velocity.runtime.VelocimacroFactory.startMacroRendering(VelocimacroFactory.java:179)
>   at 
> org.apache.velocity.runtime.RuntimeInstance.startMacroRendering(RuntimeInstance.java:1693)
>   at 
> org.apache.velocity.runtime.directive.VelocimacroProxy.render(VelocimacroProxy.java:200)
>   at 
> org.apache.velocity.runtime.directive.RuntimeMacro.render(RuntimeMacro.java:230)
>   at 
> org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:178)
>   at 
> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:323)
>   at org.apache.velocity.Template.merge(Template.java:324)
>   at org.apache.velocity.Template.merge(Template.java:232)
>   at 
> org.apache.velocity.test.load.Velocity24Test.testRendering(Velocity24Test.java:51)
> This is related to VELOCITY-297 but the fix doesn't seem work with the new 
> modified macro implementation.

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

[jira] Commented: (VELOCITY-607) Runtime macro rendering very slow in Velocity 1.6-dev (679708) compared to 1.5

[JIRA]

[ 
https://issues.apache.org/jira/browse/VELOCITY-607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617036#action_12617036
 ] 

Jarkko Viinamäki commented on VELOCITY-607:
---

Nice work Nathan! I ran tests with 250 simultaneous threads using the test but 
I didn't get the incorrect macrooverflow exception anymore. I also tested that 
infinite recursion correctly causes the exception. So your fixes seem to work 
well.

The performance is still rotten though (with 350 threads, 50 loops: 1.5: 1,3 
seconds, 1.6-dev: 46 seconds)

> Runtime macro rendering very slow in Velocity 1.6-dev (679708) compared to 1.5
> --
>
> Key: VELOCITY-607
> URL: https://issues.apache.org/jira/browse/VELOCITY-607
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
> Environment: Maven 2, JUnit, JUnitPerf, JRat, custom testbench: 
> http://www.iki.fi/wyla/velocity/testbench
>Reporter: Jarkko Viinamäki
>Priority: Critical
> Fix For: 1.6
>
> Attachments: velocity-1.5-velocity24-test.PNG, 
> velocity-1.6-head-20080725-velocity24-test.PNG
>
>
> The following test template (see VELOCITY-24):
> ## local macro, not global
> #macro(letter $char)
> This is the letter $char
> #end
> #letter("A")
> #letter("B")
> #letter("C")
> #letter("D")
> #letter("E")
> #letter("F")
> #letter("G")
> #letter("H")
> #letter("I")
> #letter("J")
> #letter("K")
> #letter("L")
> #letter("M")
> #letter("N")
> #letter("O")
> #letter("P")
> #letter("Q")
> #letter("R")
> #letter("S")
> #letter("T")
> #letter("U")
> #letter("V")
> #letter("W")
> #letter("X")
> #letter("Y")
> #letter("Z")
> ---
> Works quickly and correctly with Velocity 1.5 with several concurrent 
> threads. However, 1.6-dev is a LOT slower (even 20x).
> The major performance bottlenecks seem to be:
> RuntimeMacro.render (60% of time)
> VelocimacroFactory.getVelocimacro (20% of time)
> With several threads this test also causes Velocity to throw error(s):
> org.apache.velocity.exception.MacroOverflowException: Exceed maximum 20 macro 
> calls. Call Stack:letter->letter->letter->letter->letter
>   at 
> org.apache.velocity.runtime.VelocimacroFactory.startMacroRendering(VelocimacroFactory.java:179)
>   at 
> org.apache.velocity.runtime.RuntimeInstance.startMacroRendering(RuntimeInstance.java:1693)
>   at 
> org.apache.velocity.runtime.directive.VelocimacroProxy.render(VelocimacroProxy.java:200)
>   at 
> org.apache.velocity.runtime.directive.RuntimeMacro.render(RuntimeMacro.java:230)
>   at 
> org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:178)
>   at 
> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:323)
>   at org.apache.velocity.Template.merge(Template.java:324)
>   at org.apache.velocity.Template.merge(Template.java:232)
>   at 
> org.apache.velocity.test.load.Velocity24Test.testRendering(Velocity24Test.java:51)
> This is related to VELOCITY-297 but the fix doesn't seem work with the new 
> modified macro implementation.

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

[jira] Created: (VELOCITY-608) Maven build for velocity-site fails because of missing plexus utils dependency

[JIRA]

Maven build for velocity-site fails because of missing plexus utils dependency
--

 Key: VELOCITY-608
 URL: https://issues.apache.org/jira/browse/VELOCITY-608
 Project: Velocity
  Issue Type: Bug
  Components: Website
Reporter: Jarkko Viinamäki
 Attachments: velocity-site.patch

I checked out http://svn.apache.org/repos/asf/velocity/site/ and ran Maven 
build:

mvn site

-->

C:\work\workspace\other\velocity-site\tools\velocity-site-news-plugin\target\generated-sources\model
lo\org\apache\velocity\site\news\model\io\xpp3\NewsXpp3Reader.java:[18,31] 
cannot find symbol
symbol  : class ReaderFactory
location: package org.codehaus.plexus.util

C:\work\workspace\other\velocity-site\tools\velocity-site-news-plugin\target\generated-sources\model
lo\org\apache\velocity\site\news\model\io\xpp3\NewsXpp3Reader.java:[809,24] 
cannot find symbol
symbol  : variable ReaderFactory
location: class org.apache.velocity.site.news.model.io.xpp3.NewsXpp3Reader

C:\work\workspace\other\velocity-site\tools\velocity-site-news-plugin\target\generated-sources\model
lo\org\apache\velocity\site\news\model\io\xpp3\NewsXpp3Reader.java:[825,24] 
cannot find symbol
symbol  : variable ReaderFactory
location: class org.apache.velocity.site.news.model.io.xpp3.NewsXpp3Reader

---

to fix that, add dependency to plexus-utils in pom.xml:


  org.codehaus.plexus
  plexus-utils
  1.5.5





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

[jira] Updated: (VELOCITY-608) Maven build for velocity-site fails because of missing plexus utils dependency

[JIRA]

 [ 
https://issues.apache.org/jira/browse/VELOCITY-608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarkko Viinamäki updated VELOCITY-608:
--

Attachment: velocity-site.patch

> Maven build for velocity-site fails because of missing plexus utils dependency
> --
>
> Key: VELOCITY-608
> URL: https://issues.apache.org/jira/browse/VELOCITY-608
> Project: Velocity
>  Issue Type: Bug
>  Components: Website
>Reporter: Jarkko Viinamäki
> Attachments: velocity-site.patch
>
>
> I checked out http://svn.apache.org/repos/asf/velocity/site/ and ran Maven 
> build:
> mvn site
> -->
> C:\work\workspace\other\velocity-site\tools\velocity-site-news-plugin\target\generated-sources\model
> lo\org\apache\velocity\site\news\model\io\xpp3\NewsXpp3Reader.java:[18,31] 
> cannot find symbol
> symbol  : class ReaderFactory
> location: package org.codehaus.plexus.util
> C:\work\workspace\other\velocity-site\tools\velocity-site-news-plugin\target\generated-sources\model
> lo\org\apache\velocity\site\news\model\io\xpp3\NewsXpp3Reader.java:[809,24] 
> cannot find symbol
> symbol  : variable ReaderFactory
> location: class org.apache.velocity.site.news.model.io.xpp3.NewsXpp3Reader
> C:\work\workspace\other\velocity-site\tools\velocity-site-news-plugin\target\generated-sources\model
> lo\org\apache\velocity\site\news\model\io\xpp3\NewsXpp3Reader.java:[825,24] 
> cannot find symbol
> symbol  : variable ReaderFactory
> location: class org.apache.velocity.site.news.model.io.xpp3.NewsXpp3Reader
> ---
> to fix that, add dependency to plexus-utils in pom.xml:
> 
>   org.codehaus.plexus
>   plexus-utils
>   1.5.5
> 

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

[jira] Created: (VELOCITY-609) current velocity-site subproject produces velocity-site-skin-1.2.3.jar, velocity engine mvn site expects version 1.2.0

[JIRA]

current velocity-site subproject produces velocity-site-skin-1.2.3.jar, 
velocity engine mvn site expects version 1.2.0
--

 Key: VELOCITY-609
 URL: https://issues.apache.org/jira/browse/VELOCITY-609
 Project: Velocity
  Issue Type: Bug
  Components: Website
Reporter: Jarkko Viinamäki
Priority: Minor


I built http://svn.apache.org/repos/asf/velocity/site/site/ with Maven and it 
installed velocity-site-skin-1.2.3.jar in my local repository.

However, I still wasn't able to call "mvn site" for 
http://svn.apache.org/repos/asf/velocity/engine/trunk/ because it expects 
velocity-site-skin-1.2.0.jar.

As a quick workaround I just renamed the file in my local repository but 
there's probably a better way. :) 

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

[jira] Commented: (VELOCITY-607) Runtime macro rendering very slow in Velocity 1.6-dev (679708) compared to 1.5

[JIRA]

[ 
https://issues.apache.org/jira/browse/VELOCITY-607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617927#action_12617927
 ] 

Jarkko Viinamäki commented on VELOCITY-607:
---

Nathan is right. I have analyzed the code a lot and there is massive amount of 
rework done. Every time a macro is used, a new VelocimacroProxy is created and 
the macro is reparsed from string to AST. Then each macro argument is reparsed 
from string to AST. For each macro argument a new VMProxyArg is created. In 
addition, a new VMContext is created every time a macro is called (2 HashMaps). 
This means a lot of memory allocation which is slow and lots of garbage.

Also when the macro is parsed the first time (Macro directive) the already 
parsed AST is turned back into a String and stored.

I mercilessly refactored the code and I managed to create an implementation 
which passes all current tests and a) uses shared AST for all macros, b) uses 
shared VelocitymacroProxy c) uses call by reference for macro arguments 
(instead of call by value). With these modifications the performance is very 
close to 1.5 with the template in this issue but not quite there yet.

I'll see if I can tweak the refactored design a bit more but it's already 
several times faster than current one.

> Runtime macro rendering very slow in Velocity 1.6-dev (679708) compared to 1.5
> --
>
> Key: VELOCITY-607
> URL: https://issues.apache.org/jira/browse/VELOCITY-607
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
> Environment: Maven 2, JUnit, JUnitPerf, JRat, custom testbench: 
> http://www.iki.fi/wyla/velocity/testbench
>Reporter: Jarkko Viinamäki
>Priority: Critical
> Fix For: 1.6
>
> Attachments: velocity-1.5-velocity24-test.PNG, 
> velocity-1.6-head-20080725-velocity24-test.PNG
>
>
> The following test template (see VELOCITY-24):
> ## local macro, not global
> #macro(letter $char)
> This is the letter $char
> #end
> #letter("A")
> #letter("B")
> #letter("C")
> #letter("D")
> #letter("E")
> #letter("F")
> #letter("G")
> #letter("H")
> #letter("I")
> #letter("J")
> #letter("K")
> #letter("L")
> #letter("M")
> #letter("N")
> #letter("O")
> #letter("P")
> #letter("Q")
> #letter("R")
> #letter("S")
> #letter("T")
> #letter("U")
> #letter("V")
> #letter("W")
> #letter("X")
> #letter("Y")
> #letter("Z")
> ---
> Works quickly and correctly with Velocity 1.5 with several concurrent 
> threads. However, 1.6-dev is a LOT slower (even 20x).
> The major performance bottlenecks seem to be:
> RuntimeMacro.render (60% of time)
> VelocimacroFactory.getVelocimacro (20% of time)
> With several threads this test also causes Velocity to throw error(s):
> org.apache.velocity.exception.MacroOverflowException: Exceed maximum 20 macro 
> calls. Call Stack:letter->letter->letter->letter->letter
>   at 
> org.apache.velocity.runtime.VelocimacroFactory.startMacroRendering(VelocimacroFactory.java:179)
>   at 
> org.apache.velocity.runtime.RuntimeInstance.startMacroRendering(RuntimeInstance.java:1693)
>   at 
> org.apache.velocity.runtime.directive.VelocimacroProxy.render(VelocimacroProxy.java:200)
>   at 
> org.apache.velocity.runtime.directive.RuntimeMacro.render(RuntimeMacro.java:230)
>   at 
> org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:178)
>   at 
> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:323)
>   at org.apache.velocity.Template.merge(Template.java:324)
>   at org.apache.velocity.Template.merge(Template.java:232)
>   at 
> org.apache.velocity.test.load.Velocity24Test.testRendering(Velocity24Test.java:51)
> This is related to VELOCITY-297 but the fix doesn't seem work with the new 
> modified macro implementation.

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

[jira] Updated: (VELOCITY-607) Runtime macro rendering very slow in Velocity 1.6-dev (679708) compared to 1.5

[JIRA]

 [ 
https://issues.apache.org/jira/browse/VELOCITY-607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarkko Viinamäki updated VELOCITY-607:
--

Attachment: velocity-1.6-macro-performance-IDEAS.patch

First things first:

1. This is not a real production quality patch. It contains some ideas and 
major design changes that I tried when trying to make Velocity 1.6 new macro 
implementation perform better. I have done some functional, performance and 
load testing but not nearly enough.

2. Although tests pass, I have most probably broken some functionality 
especially regarding error messages and namespaces. 

3. I have tested these changes with several hundred concurrent threads which 
does not mean that they are free from race conditions, locking issues etc. 
nasty stuff.

4. Even after this patch Velocity 1.6 svn head is around 10-20% slower than 
1.5. I didn't investigate 1.5 code that much but I suspect that Velocity 1.5 
fully preconstructs templates by duplicating macro AST and precalculates values 
for constant macro arguments. This patch however uses shared macro ASTs which 
should reduce memory usage but introduces a bunch of new problems.

Main ideas of this patch:

1. When a macro is parsed and thrown into Macro.processAndRegister, it is not 
transformed and stored as String but as AST.

2. VelocimacroManager does not create new VelocimacroProxy for each request but 
creates one per macro / namespace. Thus threads share the macro AST.

3. VMContext and VMProxyArg have been replaced with ProxyVMContext. This allows 
us to skip parsing of macro arguments when macro is invoked and it reduces 
memory allocation overhead. 

4. "Render literal if null for references" is tricky to implement with shared 
macro AST. Velocity 1.5 implements this by preprocessing the AST tree with 
visitor.VMReferenceMungeVisitor. As far as I understand, this is not possible 
with shared macro AST. Therefore there's a rather ugly hack which puts macro 
argument references to the macro rendering context. ASTReference can then 
construct the literal format of arguments on-demand.

Other notes:

1. ExtendedProperties class is synchronized and very slow overall (it even says 
so in the JavaDocs). There are quite many runtime calls to this class 
throughout the Velocity code.

2. I haven't really investigated yet if this version even uses less memory than 
1.5. If the memory usage isn't significantly lower, I don't see much point in 
using 1.6.

3. I probably made some catastrophic design mistakes but it takes time to 
understand velocity functionality and design. Please forgive me. :)

> Runtime macro rendering very slow in Velocity 1.6-dev (679708) compared to 1.5
> --
>
> Key: VELOCITY-607
>     URL: https://issues.apache.org/jira/browse/VELOCITY-607
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
> Environment: Maven 2, JUnit, JUnitPerf, JRat, custom testbench: 
> http://www.iki.fi/wyla/velocity/testbench
>Reporter: Jarkko Viinamäki
>Priority: Critical
> Fix For: 1.6
>
> Attachments: velocity-1.5-velocity24-test.PNG, 
> velocity-1.6-head-20080725-velocity24-test.PNG, 
> velocity-1.6-macro-performance-IDEAS.patch
>
>
> The following test template (see VELOCITY-24):
> ## local macro, not global
> #macro(letter $char)
> This is the letter $char
> #end
> #letter("A")
> #letter("B")
> #letter("C")
> #letter("D")
> #letter("E")
> #letter("F")
> #letter("G")
> #letter("H")
> #letter("I")
> #letter("J")
> #letter("K")
> #letter("L")
> #letter("M")
> #letter("N")
> #letter("O")
> #letter("P")
> #letter("Q")
> #letter("R")
> #letter("S")
> #letter("T")
> #letter("U")
> #letter("V")
> #letter("W")
> #letter("X")
> #letter("Y")
> #letter("Z")
> ---
> Works quickly and correctly with Velocity 1.5 with several concurrent 
> threads. However, 1.6-dev is a LOT slower (even 20x).
> The major performance bottlenecks seem to be:
> RuntimeMacro.render (60% of time)
> VelocimacroFactory.getVelocimacro (20% of time)
> With several threads this test also causes Velocity to throw error(s):
> org.apache.velocity.exception.MacroOverflowException: Exceed maximum 20 macro 
> calls. Call Stack:letter->letter->letter->letter->letter
>   at 
> org.apache.veloc

[jira] Issue Comment Edited: (VELOCITY-607) Runtime macro rendering very slow in Velocity 1.6-dev (679708) compared to 1.5

[JIRA]

[ 
https://issues.apache.org/jira/browse/VELOCITY-607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12618316#action_12618316
 ] 

wyla edited comment on VELOCITY-607 at 7/30/08 6:00 AM:


First things first:

1. This is not a real production quality patch. It contains some ideas and 
major design changes that I tried when trying to make Velocity 1.6 new macro 
implementation perform better. I have done some functional, performance and 
load testing but not nearly enough.

2. Although tests pass, I have most probably broken some functionality 
especially regarding error messages and namespaces. 

3. I have tested these changes with several hundred concurrent threads which 
does not mean that they are free from race conditions, locking issues etc. 
nasty stuff.

4. Even after this patch Velocity 1.6 svn head is around 10-20% slower than 
1.5. I didn't investigate 1.5 code that much but I suspect that Velocity 1.5 
fully preconstructs templates by duplicating macro AST and precalculates values 
for constant macro arguments. This patch however uses shared macro ASTs which 
should reduce memory usage but introduces a bunch of new problems.

5. There are public interfaces changes (yep, bad).

Main ideas of this patch:

1. When a macro is parsed and thrown into Macro.processAndRegister, it is not 
transformed and stored as String but as AST.

2. VelocimacroManager does not create new VelocimacroProxy for each request but 
creates one per macro / namespace. Thus threads share the macro AST.

3. VMContext and VMProxyArg have been replaced with ProxyVMContext. This allows 
us to skip parsing of macro arguments when macro is invoked and it reduces 
memory allocation overhead. 

4. "Render literal if null for references" is tricky to implement with shared 
macro AST. Velocity 1.5 implements this by preprocessing the AST tree with 
visitor.VMReferenceMungeVisitor. As far as I understand, this is not possible 
with shared macro AST. Therefore there's a rather ugly hack which puts macro 
argument references to the macro rendering context. ASTReference can then 
construct the literal format of arguments on-demand.

Other notes:

1. ExtendedProperties class is synchronized and very slow overall (it even says 
so in the JavaDocs). There are quite many runtime calls to this class 
throughout the Velocity code.

2. I haven't really investigated yet if this version even uses less memory than 
1.5. If the memory usage isn't significantly lower, I don't see much point in 
using 1.6.

3. I probably made some catastrophic design mistakes but it takes time to 
understand velocity functionality and design. Please forgive me. :)

  was (Author: wyla):
First things first:

1. This is not a real production quality patch. It contains some ideas and 
major design changes that I tried when trying to make Velocity 1.6 new macro 
implementation perform better. I have done some functional, performance and 
load testing but not nearly enough.

2. Although tests pass, I have most probably broken some functionality 
especially regarding error messages and namespaces. 

3. I have tested these changes with several hundred concurrent threads which 
does not mean that they are free from race conditions, locking issues etc. 
nasty stuff.

4. Even after this patch Velocity 1.6 svn head is around 10-20% slower than 
1.5. I didn't investigate 1.5 code that much but I suspect that Velocity 1.5 
fully preconstructs templates by duplicating macro AST and precalculates values 
for constant macro arguments. This patch however uses shared macro ASTs which 
should reduce memory usage but introduces a bunch of new problems.

Main ideas of this patch:

1. When a macro is parsed and thrown into Macro.processAndRegister, it is not 
transformed and stored as String but as AST.

2. VelocimacroManager does not create new VelocimacroProxy for each request but 
creates one per macro / namespace. Thus threads share the macro AST.

3. VMContext and VMProxyArg have been replaced with ProxyVMContext. This allows 
us to skip parsing of macro arguments when macro is invoked and it reduces 
memory allocation overhead. 

4. "Render literal if null for references" is tricky to implement with shared 
macro AST. Velocity 1.5 implements this by preprocessing the AST tree with 
visitor.VMReferenceMungeVisitor. As far as I understand, this is not possible 
with shared macro AST. Therefore there's a rather ugly hack which puts macro 
argument references to the macro rendering context. ASTReference can then 
construct the literal format of arguments on-demand.

Other notes:

1. ExtendedProperties class is synchronized and very slow overall (it even says 
so in the JavaDocs). There are quite many runtime calls to this class 
throughout the Velocity code.

2. I haven't really investigated yet if t

[jira] Issue Comment Edited: (VELOCITY-607) Runtime macro rendering very slow in Velocity 1.6-dev (679708) compared to 1.5

[JIRA]

[ 
https://issues.apache.org/jira/browse/VELOCITY-607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12618316#action_12618316
 ] 

wyla edited comment on VELOCITY-607 at 7/30/08 7:22 AM:


First things first:

1. This is not a real production quality patch. It contains some ideas and 
major design changes that I tried when trying to make Velocity 1.6 new macro 
implementation perform better. I have done some functional, performance and 
load testing but not nearly enough.

2. Although tests pass, I have most probably broken some functionality 
especially regarding error messages and namespaces. 

3. I have tested these changes with several hundred concurrent threads which 
does not mean that they are free from race conditions, locking issues etc. 
nasty stuff.

4. Even after this patch Velocity 1.6 svn head is around 10-20% slower than 
1.5. I didn't investigate 1.5 code that much but I suspect that Velocity 1.5 
fully preconstructs templates by duplicating macro AST and precalculates values 
for constant macro arguments. This patch however uses shared macro ASTs which 
should reduce memory usage but introduces a bunch of new problems.

5. There are public interface changes (yep, bad).

Main ideas of this patch:

1. When a macro is parsed and thrown into Macro.processAndRegister, it is not 
transformed and stored as String but as AST.

2. VelocimacroManager does not create new VelocimacroProxy for each request but 
creates one per macro / namespace. Thus threads share the macro AST.

3. VMContext and VMProxyArg have been replaced with ProxyVMContext. This allows 
us to skip parsing of macro arguments when macro is invoked and it reduces 
memory allocation overhead. 

4. "Render literal if null for references" is tricky to implement with shared 
macro AST. Velocity 1.5 implements this by preprocessing the AST tree with 
visitor.VMReferenceMungeVisitor. As far as I understand, this is not possible 
with shared macro AST. Therefore there's a rather ugly hack which puts macro 
argument references to the macro rendering context. ASTReference can then 
construct the literal format of arguments on-demand.

Other notes:

1. ExtendedProperties class is synchronized and very slow overall (it even says 
so in the JavaDocs). There are quite many runtime calls to this class 
throughout the Velocity code.

2. I haven't really investigated yet if this version even uses less memory than 
1.5. If the memory usage isn't significantly lower, I don't see much point in 
using 1.6 if one doesn't need the new macro functionality.

3. I probably made some catastrophic design mistakes but it takes time to 
understand velocity functionality and design. Please forgive me. :)

  was (Author: wyla):
First things first:

1. This is not a real production quality patch. It contains some ideas and 
major design changes that I tried when trying to make Velocity 1.6 new macro 
implementation perform better. I have done some functional, performance and 
load testing but not nearly enough.

2. Although tests pass, I have most probably broken some functionality 
especially regarding error messages and namespaces. 

3. I have tested these changes with several hundred concurrent threads which 
does not mean that they are free from race conditions, locking issues etc. 
nasty stuff.

4. Even after this patch Velocity 1.6 svn head is around 10-20% slower than 
1.5. I didn't investigate 1.5 code that much but I suspect that Velocity 1.5 
fully preconstructs templates by duplicating macro AST and precalculates values 
for constant macro arguments. This patch however uses shared macro ASTs which 
should reduce memory usage but introduces a bunch of new problems.

5. There are public interfaces changes (yep, bad).

Main ideas of this patch:

1. When a macro is parsed and thrown into Macro.processAndRegister, it is not 
transformed and stored as String but as AST.

2. VelocimacroManager does not create new VelocimacroProxy for each request but 
creates one per macro / namespace. Thus threads share the macro AST.

3. VMContext and VMProxyArg have been replaced with ProxyVMContext. This allows 
us to skip parsing of macro arguments when macro is invoked and it reduces 
memory allocation overhead. 

4. "Render literal if null for references" is tricky to implement with shared 
macro AST. Velocity 1.5 implements this by preprocessing the AST tree with 
visitor.VMReferenceMungeVisitor. As far as I understand, this is not possible 
with shared macro AST. Therefore there's a rather ugly hack which puts macro 
argument references to the macro rendering context. ASTReference can then 
construct the literal format of arguments on-demand.

Other notes:

1. ExtendedProperties class is synchronized and very slow overall (it even says 
so in the JavaDocs). There are quite many 

[jira] Updated: (VELOCITY-607) Runtime macro rendering very slow in Velocity 1.6-dev (679708) compared to 1.5

[JIRA]

 [ 
https://issues.apache.org/jira/browse/VELOCITY-607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarkko Viinamäki updated VELOCITY-607:
--

Attachment: (was: velocity-1.6-macro-performance-IDEAS.patch)

> Runtime macro rendering very slow in Velocity 1.6-dev (679708) compared to 1.5
> --
>
> Key: VELOCITY-607
> URL: https://issues.apache.org/jira/browse/VELOCITY-607
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
> Environment: Maven 2, JUnit, JUnitPerf, JRat, custom testbench: 
> http://www.iki.fi/wyla/velocity/testbench
>Reporter: Jarkko Viinamäki
>Priority: Critical
> Fix For: 1.6
>
> Attachments: velocity-1.5-velocity24-test.PNG, 
> velocity-1.6-head-20080725-velocity24-test.PNG
>
>
> The following test template (see VELOCITY-24):
> ## local macro, not global
> #macro(letter $char)
> This is the letter $char
> #end
> #letter("A")
> #letter("B")
> #letter("C")
> #letter("D")
> #letter("E")
> #letter("F")
> #letter("G")
> #letter("H")
> #letter("I")
> #letter("J")
> #letter("K")
> #letter("L")
> #letter("M")
> #letter("N")
> #letter("O")
> #letter("P")
> #letter("Q")
> #letter("R")
> #letter("S")
> #letter("T")
> #letter("U")
> #letter("V")
> #letter("W")
> #letter("X")
> #letter("Y")
> #letter("Z")
> ---
> Works quickly and correctly with Velocity 1.5 with several concurrent 
> threads. However, 1.6-dev is a LOT slower (even 20x).
> The major performance bottlenecks seem to be:
> RuntimeMacro.render (60% of time)
> VelocimacroFactory.getVelocimacro (20% of time)
> With several threads this test also causes Velocity to throw error(s):
> org.apache.velocity.exception.MacroOverflowException: Exceed maximum 20 macro 
> calls. Call Stack:letter->letter->letter->letter->letter
>   at 
> org.apache.velocity.runtime.VelocimacroFactory.startMacroRendering(VelocimacroFactory.java:179)
>   at 
> org.apache.velocity.runtime.RuntimeInstance.startMacroRendering(RuntimeInstance.java:1693)
>   at 
> org.apache.velocity.runtime.directive.VelocimacroProxy.render(VelocimacroProxy.java:200)
>   at 
> org.apache.velocity.runtime.directive.RuntimeMacro.render(RuntimeMacro.java:230)
>   at 
> org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:178)
>   at 
> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:323)
>   at org.apache.velocity.Template.merge(Template.java:324)
>   at org.apache.velocity.Template.merge(Template.java:232)
>   at 
> org.apache.velocity.test.load.Velocity24Test.testRendering(Velocity24Test.java:51)
> This is related to VELOCITY-297 but the fix doesn't seem work with the new 
> modified macro implementation.

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

[jira] Updated: (VELOCITY-607) Runtime macro rendering very slow in Velocity 1.6-dev (679708) compared to 1.5

[JIRA]

 [ 
https://issues.apache.org/jira/browse/VELOCITY-607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarkko Viinamäki updated VELOCITY-607:
--

Attachment: velocity-1.6-dev-macro-performance-IDEAS-v2.patch

OK. I tweaked my patch a bit and removed some bottlenecks. JRat revealed that a 
lot of time is spent in ASTReference.render because of the value = 
EventHandlerUtil.referenceInsert(rsvc, context, literal(), value); call. I also 
managed to make VelocimacroProxy.render totally unsynchronized and made some 
other little tweaks here and there.

Tests still pass but I hope this doesn't break things too much.

The good news is that with some of my test templates and the test in this issue 
the patched 1.6-dev is now in some cases even 20% _faster_ than Velocity 1.5.

> Runtime macro rendering very slow in Velocity 1.6-dev (679708) compared to 1.5
> --
>
> Key: VELOCITY-607
> URL: https://issues.apache.org/jira/browse/VELOCITY-607
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
> Environment: Maven 2, JUnit, JUnitPerf, JRat, custom testbench: 
> http://www.iki.fi/wyla/velocity/testbench
>Reporter: Jarkko Viinamäki
>Priority: Critical
> Fix For: 1.6
>
> Attachments: velocity-1.5-velocity24-test.PNG, 
> velocity-1.6-dev-macro-performance-IDEAS-v2.patch, 
> velocity-1.6-head-20080725-velocity24-test.PNG
>
>
> The following test template (see VELOCITY-24):
> ## local macro, not global
> #macro(letter $char)
> This is the letter $char
> #end
> #letter("A")
> #letter("B")
> #letter("C")
> #letter("D")
> #letter("E")
> #letter("F")
> #letter("G")
> #letter("H")
> #letter("I")
> #letter("J")
> #letter("K")
> #letter("L")
> #letter("M")
> #letter("N")
> #letter("O")
> #letter("P")
> #letter("Q")
> #letter("R")
> #letter("S")
> #letter("T")
> #letter("U")
> #letter("V")
> #letter("W")
> #letter("X")
> #letter("Y")
> #letter("Z")
> ---
> Works quickly and correctly with Velocity 1.5 with several concurrent 
> threads. However, 1.6-dev is a LOT slower (even 20x).
> The major performance bottlenecks seem to be:
> RuntimeMacro.render (60% of time)
> VelocimacroFactory.getVelocimacro (20% of time)
> With several threads this test also causes Velocity to throw error(s):
> org.apache.velocity.exception.MacroOverflowException: Exceed maximum 20 macro 
> calls. Call Stack:letter->letter->letter->letter->letter
>   at 
> org.apache.velocity.runtime.VelocimacroFactory.startMacroRendering(VelocimacroFactory.java:179)
>   at 
> org.apache.velocity.runtime.RuntimeInstance.startMacroRendering(RuntimeInstance.java:1693)
>   at 
> org.apache.velocity.runtime.directive.VelocimacroProxy.render(VelocimacroProxy.java:200)
>   at 
> org.apache.velocity.runtime.directive.RuntimeMacro.render(RuntimeMacro.java:230)
>   at 
> org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:178)
>   at 
> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:323)
>   at org.apache.velocity.Template.merge(Template.java:324)
>   at org.apache.velocity.Template.merge(Template.java:232)
>   at 
> org.apache.velocity.test.load.Velocity24Test.testRendering(Velocity24Test.java:51)
> This is related to VELOCITY-297 but the fix doesn't seem work with the new 
> modified macro implementation.

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

[jira] Updated: (VELOCITY-607) Runtime macro rendering very slow in Velocity 1.6-dev (679708) compared to 1.5

[JIRA]

 [ 
https://issues.apache.org/jira/browse/VELOCITY-607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarkko Viinamäki updated VELOCITY-607:
--

Attachment: velocity-1.6-dev-macro-performance-IDEAS-v2.1.patch

Some cleanup and Javadoc fixes. Also fixes a log problem which occurs when 
multiple concurrent threads parse and try to add the same macro simultaneously. 
This caused unnecessary spam in the log.

> Runtime macro rendering very slow in Velocity 1.6-dev (679708) compared to 1.5
> --
>
> Key: VELOCITY-607
> URL: https://issues.apache.org/jira/browse/VELOCITY-607
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
> Environment: Maven 2, JUnit, JUnitPerf, JRat, custom testbench: 
> http://www.iki.fi/wyla/velocity/testbench
>Reporter: Jarkko Viinamäki
>Priority: Critical
> Fix For: 1.6
>
> Attachments: velocity-1.5-velocity24-test.PNG, 
> velocity-1.6-dev-macro-performance-IDEAS-v2.1.patch, 
> velocity-1.6-head-20080725-velocity24-test.PNG
>
>
> The following test template (see VELOCITY-24):
> ## local macro, not global
> #macro(letter $char)
> This is the letter $char
> #end
> #letter("A")
> #letter("B")
> #letter("C")
> #letter("D")
> #letter("E")
> #letter("F")
> #letter("G")
> #letter("H")
> #letter("I")
> #letter("J")
> #letter("K")
> #letter("L")
> #letter("M")
> #letter("N")
> #letter("O")
> #letter("P")
> #letter("Q")
> #letter("R")
> #letter("S")
> #letter("T")
> #letter("U")
> #letter("V")
> #letter("W")
> #letter("X")
> #letter("Y")
> #letter("Z")
> ---
> Works quickly and correctly with Velocity 1.5 with several concurrent 
> threads. However, 1.6-dev is a LOT slower (even 20x).
> The major performance bottlenecks seem to be:
> RuntimeMacro.render (60% of time)
> VelocimacroFactory.getVelocimacro (20% of time)
> With several threads this test also causes Velocity to throw error(s):
> org.apache.velocity.exception.MacroOverflowException: Exceed maximum 20 macro 
> calls. Call Stack:letter->letter->letter->letter->letter
>   at 
> org.apache.velocity.runtime.VelocimacroFactory.startMacroRendering(VelocimacroFactory.java:179)
>   at 
> org.apache.velocity.runtime.RuntimeInstance.startMacroRendering(RuntimeInstance.java:1693)
>   at 
> org.apache.velocity.runtime.directive.VelocimacroProxy.render(VelocimacroProxy.java:200)
>   at 
> org.apache.velocity.runtime.directive.RuntimeMacro.render(RuntimeMacro.java:230)
>   at 
> org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:178)
>   at 
> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:323)
>   at org.apache.velocity.Template.merge(Template.java:324)
>   at org.apache.velocity.Template.merge(Template.java:232)
>   at 
> org.apache.velocity.test.load.Velocity24Test.testRendering(Velocity24Test.java:51)
> This is related to VELOCITY-297 but the fix doesn't seem work with the new 
> modified macro implementation.

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

[jira] Updated: (VELOCITY-607) Runtime macro rendering very slow in Velocity 1.6-dev (679708) compared to 1.5

[JIRA]

 [ 
https://issues.apache.org/jira/browse/VELOCITY-607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarkko Viinamäki updated VELOCITY-607:
--

Attachment: (was: velocity-1.6-dev-macro-performance-IDEAS-v2.patch)

> Runtime macro rendering very slow in Velocity 1.6-dev (679708) compared to 1.5
> --
>
> Key: VELOCITY-607
> URL: https://issues.apache.org/jira/browse/VELOCITY-607
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
> Environment: Maven 2, JUnit, JUnitPerf, JRat, custom testbench: 
> http://www.iki.fi/wyla/velocity/testbench
>Reporter: Jarkko Viinamäki
>Priority: Critical
> Fix For: 1.6
>
> Attachments: velocity-1.5-velocity24-test.PNG, 
> velocity-1.6-dev-macro-performance-IDEAS-v2.1.patch, 
> velocity-1.6-head-20080725-velocity24-test.PNG
>
>
> The following test template (see VELOCITY-24):
> ## local macro, not global
> #macro(letter $char)
> This is the letter $char
> #end
> #letter("A")
> #letter("B")
> #letter("C")
> #letter("D")
> #letter("E")
> #letter("F")
> #letter("G")
> #letter("H")
> #letter("I")
> #letter("J")
> #letter("K")
> #letter("L")
> #letter("M")
> #letter("N")
> #letter("O")
> #letter("P")
> #letter("Q")
> #letter("R")
> #letter("S")
> #letter("T")
> #letter("U")
> #letter("V")
> #letter("W")
> #letter("X")
> #letter("Y")
> #letter("Z")
> ---
> Works quickly and correctly with Velocity 1.5 with several concurrent 
> threads. However, 1.6-dev is a LOT slower (even 20x).
> The major performance bottlenecks seem to be:
> RuntimeMacro.render (60% of time)
> VelocimacroFactory.getVelocimacro (20% of time)
> With several threads this test also causes Velocity to throw error(s):
> org.apache.velocity.exception.MacroOverflowException: Exceed maximum 20 macro 
> calls. Call Stack:letter->letter->letter->letter->letter
>   at 
> org.apache.velocity.runtime.VelocimacroFactory.startMacroRendering(VelocimacroFactory.java:179)
>   at 
> org.apache.velocity.runtime.RuntimeInstance.startMacroRendering(RuntimeInstance.java:1693)
>   at 
> org.apache.velocity.runtime.directive.VelocimacroProxy.render(VelocimacroProxy.java:200)
>   at 
> org.apache.velocity.runtime.directive.RuntimeMacro.render(RuntimeMacro.java:230)
>   at 
> org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:178)
>   at 
> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:323)
>   at org.apache.velocity.Template.merge(Template.java:324)
>   at org.apache.velocity.Template.merge(Template.java:232)
>   at 
> org.apache.velocity.test.load.Velocity24Test.testRendering(Velocity24Test.java:51)
> This is related to VELOCITY-297 but the fix doesn't seem work with the new 
> modified macro implementation.

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

[jira] Issue Comment Edited: (VELOCITY-607) Runtime macro rendering very slow in Velocity 1.6-dev (679708) compared to 1.5

[JIRA]

[ 
https://issues.apache.org/jira/browse/VELOCITY-607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12618954#action_12618954
 ] 

wyla edited comment on VELOCITY-607 at 8/1/08 1:41 AM:
---

Some cleanup and Javadoc fixes. Also fixes a log problem which occurs when 
multiple concurrent threads parse and try to add the same macro simultaneously. 
This caused unnecessary spam in the log.

I confirmed with Eclipse Memory Analyzer (which is a great tool BTW!) that 
Velocity 1.6-dev with this patch uses significantly less memory (because macro 
AST is shared). I made a template with dozens of macro calls to a macro which 
has huge amounts of text. Velocity 1.5 ended up with 80 MB heap, patched 
1.6-dev with 4,5 MB heap.

  was (Author: wyla):
Some cleanup and Javadoc fixes. Also fixes a log problem which occurs when 
multiple concurrent threads parse and try to add the same macro simultaneously. 
This caused unnecessary spam in the log.
  
> Runtime macro rendering very slow in Velocity 1.6-dev (679708) compared to 1.5
> --
>
> Key: VELOCITY-607
> URL: https://issues.apache.org/jira/browse/VELOCITY-607
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
> Environment: Maven 2, JUnit, JUnitPerf, JRat, custom testbench: 
> http://www.iki.fi/wyla/velocity/testbench
>Reporter: Jarkko Viinamäki
>Priority: Critical
> Fix For: 1.6
>
> Attachments: velocity-1.5-velocity24-test.PNG, 
> velocity-1.6-dev-macro-performance-IDEAS-v2.1.patch, 
> velocity-1.6-head-20080725-velocity24-test.PNG
>
>
> The following test template (see VELOCITY-24):
> ## local macro, not global
> #macro(letter $char)
> This is the letter $char
> #end
> #letter("A")
> #letter("B")
> #letter("C")
> #letter("D")
> #letter("E")
> #letter("F")
> #letter("G")
> #letter("H")
> #letter("I")
> #letter("J")
> #letter("K")
> #letter("L")
> #letter("M")
> #letter("N")
> #letter("O")
> #letter("P")
> #letter("Q")
> #letter("R")
> #letter("S")
> #letter("T")
> #letter("U")
> #letter("V")
> #letter("W")
> #letter("X")
> #letter("Y")
> #letter("Z")
> ---
> Works quickly and correctly with Velocity 1.5 with several concurrent 
> threads. However, 1.6-dev is a LOT slower (even 20x).
> The major performance bottlenecks seem to be:
> RuntimeMacro.render (60% of time)
> VelocimacroFactory.getVelocimacro (20% of time)
> With several threads this test also causes Velocity to throw error(s):
> org.apache.velocity.exception.MacroOverflowException: Exceed maximum 20 macro 
> calls. Call Stack:letter->letter->letter->letter->letter
>   at 
> org.apache.velocity.runtime.VelocimacroFactory.startMacroRendering(VelocimacroFactory.java:179)
>   at 
> org.apache.velocity.runtime.RuntimeInstance.startMacroRendering(RuntimeInstance.java:1693)
>   at 
> org.apache.velocity.runtime.directive.VelocimacroProxy.render(VelocimacroProxy.java:200)
>   at 
> org.apache.velocity.runtime.directive.RuntimeMacro.render(RuntimeMacro.java:230)
>   at 
> org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:178)
>   at 
> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:323)
>   at org.apache.velocity.Template.merge(Template.java:324)
>   at org.apache.velocity.Template.merge(Template.java:232)
>   at 
> org.apache.velocity.test.load.Velocity24Test.testRendering(Velocity24Test.java:51)
> This is related to VELOCITY-297 but the fix doesn't seem work with the new 
> modified macro implementation.

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

[jira] Updated: (VELOCITY-607) Runtime macro rendering very slow in Velocity 1.6-dev (679708) compared to 1.5

[JIRA]

 [ 
https://issues.apache.org/jira/browse/VELOCITY-607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarkko Viinamäki updated VELOCITY-607:
--

Attachment: (was: velocity-1.6-dev-macro-performance-IDEAS-v2.1.patch)

> Runtime macro rendering very slow in Velocity 1.6-dev (679708) compared to 1.5
> --
>
> Key: VELOCITY-607
> URL: https://issues.apache.org/jira/browse/VELOCITY-607
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
> Environment: Maven 2, JUnit, JUnitPerf, JRat, custom testbench: 
> http://www.iki.fi/wyla/velocity/testbench
>Reporter: Jarkko Viinamäki
>Priority: Critical
> Fix For: 1.6
>
> Attachments: velocity-1.5-velocity24-test.PNG, 
> velocity-1.6-head-20080725-velocity24-test.PNG
>
>
> The following test template (see VELOCITY-24):
> ## local macro, not global
> #macro(letter $char)
> This is the letter $char
> #end
> #letter("A")
> #letter("B")
> #letter("C")
> #letter("D")
> #letter("E")
> #letter("F")
> #letter("G")
> #letter("H")
> #letter("I")
> #letter("J")
> #letter("K")
> #letter("L")
> #letter("M")
> #letter("N")
> #letter("O")
> #letter("P")
> #letter("Q")
> #letter("R")
> #letter("S")
> #letter("T")
> #letter("U")
> #letter("V")
> #letter("W")
> #letter("X")
> #letter("Y")
> #letter("Z")
> ---
> Works quickly and correctly with Velocity 1.5 with several concurrent 
> threads. However, 1.6-dev is a LOT slower (even 20x).
> The major performance bottlenecks seem to be:
> RuntimeMacro.render (60% of time)
> VelocimacroFactory.getVelocimacro (20% of time)
> With several threads this test also causes Velocity to throw error(s):
> org.apache.velocity.exception.MacroOverflowException: Exceed maximum 20 macro 
> calls. Call Stack:letter->letter->letter->letter->letter
>   at 
> org.apache.velocity.runtime.VelocimacroFactory.startMacroRendering(VelocimacroFactory.java:179)
>   at 
> org.apache.velocity.runtime.RuntimeInstance.startMacroRendering(RuntimeInstance.java:1693)
>   at 
> org.apache.velocity.runtime.directive.VelocimacroProxy.render(VelocimacroProxy.java:200)
>   at 
> org.apache.velocity.runtime.directive.RuntimeMacro.render(RuntimeMacro.java:230)
>   at 
> org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:178)
>   at 
> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:323)
>   at org.apache.velocity.Template.merge(Template.java:324)
>   at org.apache.velocity.Template.merge(Template.java:232)
>   at 
> org.apache.velocity.test.load.Velocity24Test.testRendering(Velocity24Test.java:51)
> This is related to VELOCITY-297 but the fix doesn't seem work with the new 
> modified macro implementation.

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

[jira] Updated: (VELOCITY-607) Runtime macro rendering very slow in Velocity 1.6-dev (679708) compared to 1.5

[JIRA]

 [ 
https://issues.apache.org/jira/browse/VELOCITY-607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarkko Viinamäki updated VELOCITY-607:
--

Attachment: velocity-1.6-dev-macro-performance-IDEAS-v2.2.patch

Latest attachment includes final tweaks to improve performance. I'll start 
waiting for feedback on these changes. With these changes 1.6-dev is 10-20% 
faster than 1.5 with the tests I ran (on single core laptop).

Interestingly the creation of the macro context in VelocimacroProxy.render 
method costs a lot of time because of the memory allocation. There's no easy 
way to avoid this though.

> Runtime macro rendering very slow in Velocity 1.6-dev (679708) compared to 1.5
> --
>
> Key: VELOCITY-607
> URL: https://issues.apache.org/jira/browse/VELOCITY-607
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
> Environment: Maven 2, JUnit, JUnitPerf, JRat, custom testbench: 
> http://www.iki.fi/wyla/velocity/testbench
>Reporter: Jarkko Viinamäki
>Priority: Critical
> Fix For: 1.6
>
> Attachments: velocity-1.5-velocity24-test.PNG, 
> velocity-1.6-dev-macro-performance-IDEAS-v2.2.patch, 
> velocity-1.6-head-20080725-velocity24-test.PNG
>
>
> The following test template (see VELOCITY-24):
> ## local macro, not global
> #macro(letter $char)
> This is the letter $char
> #end
> #letter("A")
> #letter("B")
> #letter("C")
> #letter("D")
> #letter("E")
> #letter("F")
> #letter("G")
> #letter("H")
> #letter("I")
> #letter("J")
> #letter("K")
> #letter("L")
> #letter("M")
> #letter("N")
> #letter("O")
> #letter("P")
> #letter("Q")
> #letter("R")
> #letter("S")
> #letter("T")
> #letter("U")
> #letter("V")
> #letter("W")
> #letter("X")
> #letter("Y")
> #letter("Z")
> ---
> Works quickly and correctly with Velocity 1.5 with several concurrent 
> threads. However, 1.6-dev is a LOT slower (even 20x).
> The major performance bottlenecks seem to be:
> RuntimeMacro.render (60% of time)
> VelocimacroFactory.getVelocimacro (20% of time)
> With several threads this test also causes Velocity to throw error(s):
> org.apache.velocity.exception.MacroOverflowException: Exceed maximum 20 macro 
> calls. Call Stack:letter->letter->letter->letter->letter
>   at 
> org.apache.velocity.runtime.VelocimacroFactory.startMacroRendering(VelocimacroFactory.java:179)
>   at 
> org.apache.velocity.runtime.RuntimeInstance.startMacroRendering(RuntimeInstance.java:1693)
>   at 
> org.apache.velocity.runtime.directive.VelocimacroProxy.render(VelocimacroProxy.java:200)
>   at 
> org.apache.velocity.runtime.directive.RuntimeMacro.render(RuntimeMacro.java:230)
>   at 
> org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:178)
>   at 
> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:323)
>   at org.apache.velocity.Template.merge(Template.java:324)
>   at org.apache.velocity.Template.merge(Template.java:232)
>   at 
> org.apache.velocity.test.load.Velocity24Test.testRendering(Velocity24Test.java:51)
> This is related to VELOCITY-297 but the fix doesn't seem work with the new 
> modified macro implementation.

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

[jira] Updated: (VELOCITY-607) Runtime macro rendering very slow in Velocity 1.6-dev (679708) compared to 1.5

[JIRA]

 [ 
https://issues.apache.org/jira/browse/VELOCITY-607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarkko Viinamäki updated VELOCITY-607:
--

Attachment: (was: velocity-1.6-dev-macro-performance-IDEAS-v2.2.patch)

> Runtime macro rendering very slow in Velocity 1.6-dev (679708) compared to 1.5
> --
>
> Key: VELOCITY-607
> URL: https://issues.apache.org/jira/browse/VELOCITY-607
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
> Environment: Maven 2, JUnit, JUnitPerf, JRat, custom testbench: 
> http://www.iki.fi/wyla/velocity/testbench
>Reporter: Jarkko Viinamäki
>Priority: Critical
> Fix For: 1.6
>
> Attachments: velocity-1.5-velocity24-test.PNG, 
> velocity-1.6-head-20080725-velocity24-test.PNG
>
>
> The following test template (see VELOCITY-24):
> ## local macro, not global
> #macro(letter $char)
> This is the letter $char
> #end
> #letter("A")
> #letter("B")
> #letter("C")
> #letter("D")
> #letter("E")
> #letter("F")
> #letter("G")
> #letter("H")
> #letter("I")
> #letter("J")
> #letter("K")
> #letter("L")
> #letter("M")
> #letter("N")
> #letter("O")
> #letter("P")
> #letter("Q")
> #letter("R")
> #letter("S")
> #letter("T")
> #letter("U")
> #letter("V")
> #letter("W")
> #letter("X")
> #letter("Y")
> #letter("Z")
> ---
> Works quickly and correctly with Velocity 1.5 with several concurrent 
> threads. However, 1.6-dev is a LOT slower (even 20x).
> The major performance bottlenecks seem to be:
> RuntimeMacro.render (60% of time)
> VelocimacroFactory.getVelocimacro (20% of time)
> With several threads this test also causes Velocity to throw error(s):
> org.apache.velocity.exception.MacroOverflowException: Exceed maximum 20 macro 
> calls. Call Stack:letter->letter->letter->letter->letter
>   at 
> org.apache.velocity.runtime.VelocimacroFactory.startMacroRendering(VelocimacroFactory.java:179)
>   at 
> org.apache.velocity.runtime.RuntimeInstance.startMacroRendering(RuntimeInstance.java:1693)
>   at 
> org.apache.velocity.runtime.directive.VelocimacroProxy.render(VelocimacroProxy.java:200)
>   at 
> org.apache.velocity.runtime.directive.RuntimeMacro.render(RuntimeMacro.java:230)
>   at 
> org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:178)
>   at 
> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:323)
>   at org.apache.velocity.Template.merge(Template.java:324)
>   at org.apache.velocity.Template.merge(Template.java:232)
>   at 
> org.apache.velocity.test.load.Velocity24Test.testRendering(Velocity24Test.java:51)
> This is related to VELOCITY-297 but the fix doesn't seem work with the new 
> modified macro implementation.

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

[jira] Updated: (VELOCITY-607) Runtime macro rendering very slow in Velocity 1.6-dev (679708) compared to 1.5

[JIRA]

 [ 
https://issues.apache.org/jira/browse/VELOCITY-607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarkko Viinamäki updated VELOCITY-607:
--

Attachment: velocity-1.6-dev-macro-performance-IDEAS-v2.3.patch

Removed some tweaks that didn't accomplish anything. This is now about as fast 
as I can make it.

> Runtime macro rendering very slow in Velocity 1.6-dev (679708) compared to 1.5
> --
>
> Key: VELOCITY-607
> URL: https://issues.apache.org/jira/browse/VELOCITY-607
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
> Environment: Maven 2, JUnit, JUnitPerf, JRat, custom testbench: 
> http://www.iki.fi/wyla/velocity/testbench
>Reporter: Jarkko Viinamäki
>Priority: Critical
> Fix For: 1.6
>
> Attachments: velocity-1.5-velocity24-test.PNG, 
> velocity-1.6-dev-macro-performance-IDEAS-v2.3.patch, 
> velocity-1.6-head-20080725-velocity24-test.PNG
>
>
> The following test template (see VELOCITY-24):
> ## local macro, not global
> #macro(letter $char)
> This is the letter $char
> #end
> #letter("A")
> #letter("B")
> #letter("C")
> #letter("D")
> #letter("E")
> #letter("F")
> #letter("G")
> #letter("H")
> #letter("I")
> #letter("J")
> #letter("K")
> #letter("L")
> #letter("M")
> #letter("N")
> #letter("O")
> #letter("P")
> #letter("Q")
> #letter("R")
> #letter("S")
> #letter("T")
> #letter("U")
> #letter("V")
> #letter("W")
> #letter("X")
> #letter("Y")
> #letter("Z")
> ---
> Works quickly and correctly with Velocity 1.5 with several concurrent 
> threads. However, 1.6-dev is a LOT slower (even 20x).
> The major performance bottlenecks seem to be:
> RuntimeMacro.render (60% of time)
> VelocimacroFactory.getVelocimacro (20% of time)
> With several threads this test also causes Velocity to throw error(s):
> org.apache.velocity.exception.MacroOverflowException: Exceed maximum 20 macro 
> calls. Call Stack:letter->letter->letter->letter->letter
>   at 
> org.apache.velocity.runtime.VelocimacroFactory.startMacroRendering(VelocimacroFactory.java:179)
>   at 
> org.apache.velocity.runtime.RuntimeInstance.startMacroRendering(RuntimeInstance.java:1693)
>   at 
> org.apache.velocity.runtime.directive.VelocimacroProxy.render(VelocimacroProxy.java:200)
>   at 
> org.apache.velocity.runtime.directive.RuntimeMacro.render(RuntimeMacro.java:230)
>   at 
> org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:178)
>   at 
> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:323)
>   at org.apache.velocity.Template.merge(Template.java:324)
>   at org.apache.velocity.Template.merge(Template.java:232)
>   at 
> org.apache.velocity.test.load.Velocity24Test.testRendering(Velocity24Test.java:51)
> This is related to VELOCITY-297 but the fix doesn't seem work with the new 
> modified macro implementation.

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

[jira] Updated: (VELOCITY-607) Runtime macro rendering very slow in Velocity 1.6-dev (679708) compared to 1.5

[JIRA]

 [ 
https://issues.apache.org/jira/browse/VELOCITY-607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarkko Viinamäki updated VELOCITY-607:
--

Attachment: (was: velocity-1.6-dev-macro-performance-IDEAS-v2.3.patch)

> Runtime macro rendering very slow in Velocity 1.6-dev (679708) compared to 1.5
> --
>
> Key: VELOCITY-607
> URL: https://issues.apache.org/jira/browse/VELOCITY-607
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
> Environment: Maven 2, JUnit, JUnitPerf, JRat, custom testbench: 
> http://www.iki.fi/wyla/velocity/testbench
>Reporter: Jarkko Viinamäki
>Priority: Critical
> Fix For: 1.6
>
> Attachments: velocity-1.5-velocity24-test.PNG, 
> velocity-1.6-head-20080725-velocity24-test.PNG
>
>
> The following test template (see VELOCITY-24):
> ## local macro, not global
> #macro(letter $char)
> This is the letter $char
> #end
> #letter("A")
> #letter("B")
> #letter("C")
> #letter("D")
> #letter("E")
> #letter("F")
> #letter("G")
> #letter("H")
> #letter("I")
> #letter("J")
> #letter("K")
> #letter("L")
> #letter("M")
> #letter("N")
> #letter("O")
> #letter("P")
> #letter("Q")
> #letter("R")
> #letter("S")
> #letter("T")
> #letter("U")
> #letter("V")
> #letter("W")
> #letter("X")
> #letter("Y")
> #letter("Z")
> ---
> Works quickly and correctly with Velocity 1.5 with several concurrent 
> threads. However, 1.6-dev is a LOT slower (even 20x).
> The major performance bottlenecks seem to be:
> RuntimeMacro.render (60% of time)
> VelocimacroFactory.getVelocimacro (20% of time)
> With several threads this test also causes Velocity to throw error(s):
> org.apache.velocity.exception.MacroOverflowException: Exceed maximum 20 macro 
> calls. Call Stack:letter->letter->letter->letter->letter
>   at 
> org.apache.velocity.runtime.VelocimacroFactory.startMacroRendering(VelocimacroFactory.java:179)
>   at 
> org.apache.velocity.runtime.RuntimeInstance.startMacroRendering(RuntimeInstance.java:1693)
>   at 
> org.apache.velocity.runtime.directive.VelocimacroProxy.render(VelocimacroProxy.java:200)
>   at 
> org.apache.velocity.runtime.directive.RuntimeMacro.render(RuntimeMacro.java:230)
>   at 
> org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:178)
>   at 
> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:323)
>   at org.apache.velocity.Template.merge(Template.java:324)
>   at org.apache.velocity.Template.merge(Template.java:232)
>   at 
> org.apache.velocity.test.load.Velocity24Test.testRendering(Velocity24Test.java:51)
> This is related to VELOCITY-297 but the fix doesn't seem work with the new 
> modified macro implementation.

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

[jira] Updated: (VELOCITY-607) Runtime macro rendering very slow in Velocity 1.6-dev (679708) compared to 1.5

[JIRA]

 [ 
https://issues.apache.org/jira/browse/VELOCITY-607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarkko Viinamäki updated VELOCITY-607:
--

Attachment: velocity-1.6-dev-macro-performance-IDEAS-v2.4.patch

> Runtime macro rendering very slow in Velocity 1.6-dev (679708) compared to 1.5
> --
>
> Key: VELOCITY-607
> URL: https://issues.apache.org/jira/browse/VELOCITY-607
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
> Environment: Maven 2, JUnit, JUnitPerf, JRat, custom testbench: 
> http://www.iki.fi/wyla/velocity/testbench
>Reporter: Jarkko Viinamäki
>Priority: Critical
> Fix For: 1.6
>
> Attachments: velocity-1.5-velocity24-test.PNG, 
> velocity-1.6-dev-macro-performance-IDEAS-v2.4.patch, 
> velocity-1.6-head-20080725-velocity24-test.PNG
>
>
> The following test template (see VELOCITY-24):
> ## local macro, not global
> #macro(letter $char)
> This is the letter $char
> #end
> #letter("A")
> #letter("B")
> #letter("C")
> #letter("D")
> #letter("E")
> #letter("F")
> #letter("G")
> #letter("H")
> #letter("I")
> #letter("J")
> #letter("K")
> #letter("L")
> #letter("M")
> #letter("N")
> #letter("O")
> #letter("P")
> #letter("Q")
> #letter("R")
> #letter("S")
> #letter("T")
> #letter("U")
> #letter("V")
> #letter("W")
> #letter("X")
> #letter("Y")
> #letter("Z")
> ---
> Works quickly and correctly with Velocity 1.5 with several concurrent 
> threads. However, 1.6-dev is a LOT slower (even 20x).
> The major performance bottlenecks seem to be:
> RuntimeMacro.render (60% of time)
> VelocimacroFactory.getVelocimacro (20% of time)
> With several threads this test also causes Velocity to throw error(s):
> org.apache.velocity.exception.MacroOverflowException: Exceed maximum 20 macro 
> calls. Call Stack:letter->letter->letter->letter->letter
>   at 
> org.apache.velocity.runtime.VelocimacroFactory.startMacroRendering(VelocimacroFactory.java:179)
>   at 
> org.apache.velocity.runtime.RuntimeInstance.startMacroRendering(RuntimeInstance.java:1693)
>   at 
> org.apache.velocity.runtime.directive.VelocimacroProxy.render(VelocimacroProxy.java:200)
>   at 
> org.apache.velocity.runtime.directive.RuntimeMacro.render(RuntimeMacro.java:230)
>   at 
> org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:178)
>   at 
> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:323)
>   at org.apache.velocity.Template.merge(Template.java:324)
>   at org.apache.velocity.Template.merge(Template.java:232)
>   at 
> org.apache.velocity.test.load.Velocity24Test.testRendering(Velocity24Test.java:51)
> This is related to VELOCITY-297 but the fix doesn't seem work with the new 
> modified macro implementation.

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

[jira] Updated: (VELOCITY-607) Runtime macro rendering very slow in Velocity 1.6-dev (679708) compared to 1.5

[JIRA]

 [ 
https://issues.apache.org/jira/browse/VELOCITY-607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarkko Viinamäki updated VELOCITY-607:
--

Attachment: (was: velocity-1.6-dev-macro-performance-IDEAS-v2.4.patch)

> Runtime macro rendering very slow in Velocity 1.6-dev (679708) compared to 1.5
> --
>
> Key: VELOCITY-607
> URL: https://issues.apache.org/jira/browse/VELOCITY-607
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
> Environment: Maven 2, JUnit, JUnitPerf, JRat, custom testbench: 
> http://www.iki.fi/wyla/velocity/testbench
>Reporter: Jarkko Viinamäki
>Priority: Critical
> Fix For: 1.6
>
> Attachments: velocity-1.5-velocity24-test.PNG, 
> velocity-1.6-head-20080725-velocity24-test.PNG
>
>
> The following test template (see VELOCITY-24):
> ## local macro, not global
> #macro(letter $char)
> This is the letter $char
> #end
> #letter("A")
> #letter("B")
> #letter("C")
> #letter("D")
> #letter("E")
> #letter("F")
> #letter("G")
> #letter("H")
> #letter("I")
> #letter("J")
> #letter("K")
> #letter("L")
> #letter("M")
> #letter("N")
> #letter("O")
> #letter("P")
> #letter("Q")
> #letter("R")
> #letter("S")
> #letter("T")
> #letter("U")
> #letter("V")
> #letter("W")
> #letter("X")
> #letter("Y")
> #letter("Z")
> ---
> Works quickly and correctly with Velocity 1.5 with several concurrent 
> threads. However, 1.6-dev is a LOT slower (even 20x).
> The major performance bottlenecks seem to be:
> RuntimeMacro.render (60% of time)
> VelocimacroFactory.getVelocimacro (20% of time)
> With several threads this test also causes Velocity to throw error(s):
> org.apache.velocity.exception.MacroOverflowException: Exceed maximum 20 macro 
> calls. Call Stack:letter->letter->letter->letter->letter
>   at 
> org.apache.velocity.runtime.VelocimacroFactory.startMacroRendering(VelocimacroFactory.java:179)
>   at 
> org.apache.velocity.runtime.RuntimeInstance.startMacroRendering(RuntimeInstance.java:1693)
>   at 
> org.apache.velocity.runtime.directive.VelocimacroProxy.render(VelocimacroProxy.java:200)
>   at 
> org.apache.velocity.runtime.directive.RuntimeMacro.render(RuntimeMacro.java:230)
>   at 
> org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:178)
>   at 
> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:323)
>   at org.apache.velocity.Template.merge(Template.java:324)
>   at org.apache.velocity.Template.merge(Template.java:232)
>   at 
> org.apache.velocity.test.load.Velocity24Test.testRendering(Velocity24Test.java:51)
> This is related to VELOCITY-297 but the fix doesn't seem work with the new 
> modified macro implementation.

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

[jira] Updated: (VELOCITY-607) Runtime macro rendering very slow in Velocity 1.6-dev (679708) compared to 1.5

[JIRA]

 [ 
https://issues.apache.org/jira/browse/VELOCITY-607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarkko Viinamäki updated VELOCITY-607:
--

Attachment: velocity-1.6-dev-macro-performance-IDEAS-v2.5.patch

Patch version 2.5 fixes a bug found by Erron Austin. Thanks for testing! The 
reason was that Template and ContentResource didn't initialize type by setType 
in their constructor. There was also another bug in refreshResource (call to 
newResource.setModificationCheckInterval was missing). 

I created a JUnit testcase but it's not completely automatic yet (you have to 
manually modify template files while the test is running) so I won't include it 
here yet.

> Runtime macro rendering very slow in Velocity 1.6-dev (679708) compared to 1.5
> --
>
> Key: VELOCITY-607
> URL: https://issues.apache.org/jira/browse/VELOCITY-607
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
> Environment: Maven 2, JUnit, JUnitPerf, JRat, custom testbench: 
> http://www.iki.fi/wyla/velocity/testbench
>Reporter: Jarkko Viinamäki
>Priority: Critical
> Fix For: 1.6
>
> Attachments: velocity-1.5-velocity24-test.PNG, 
> velocity-1.6-dev-macro-performance-IDEAS-v2.5.patch, 
> velocity-1.6-head-20080725-velocity24-test.PNG
>
>
> The following test template (see VELOCITY-24):
> ## local macro, not global
> #macro(letter $char)
> This is the letter $char
> #end
> #letter("A")
> #letter("B")
> #letter("C")
> #letter("D")
> #letter("E")
> #letter("F")
> #letter("G")
> #letter("H")
> #letter("I")
> #letter("J")
> #letter("K")
> #letter("L")
> #letter("M")
> #letter("N")
> #letter("O")
> #letter("P")
> #letter("Q")
> #letter("R")
> #letter("S")
> #letter("T")
> #letter("U")
> #letter("V")
> #letter("W")
> #letter("X")
> #letter("Y")
> #letter("Z")
> ---
> Works quickly and correctly with Velocity 1.5 with several concurrent 
> threads. However, 1.6-dev is a LOT slower (even 20x).
> The major performance bottlenecks seem to be:
> RuntimeMacro.render (60% of time)
> VelocimacroFactory.getVelocimacro (20% of time)
> With several threads this test also causes Velocity to throw error(s):
> org.apache.velocity.exception.MacroOverflowException: Exceed maximum 20 macro 
> calls. Call Stack:letter->letter->letter->letter->letter
>   at 
> org.apache.velocity.runtime.VelocimacroFactory.startMacroRendering(VelocimacroFactory.java:179)
>   at 
> org.apache.velocity.runtime.RuntimeInstance.startMacroRendering(RuntimeInstance.java:1693)
>   at 
> org.apache.velocity.runtime.directive.VelocimacroProxy.render(VelocimacroProxy.java:200)
>   at 
> org.apache.velocity.runtime.directive.RuntimeMacro.render(RuntimeMacro.java:230)
>   at 
> org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:178)
>   at 
> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:323)
>   at org.apache.velocity.Template.merge(Template.java:324)
>   at org.apache.velocity.Template.merge(Template.java:232)
>   at 
> org.apache.velocity.test.load.Velocity24Test.testRendering(Velocity24Test.java:51)
> This is related to VELOCITY-297 but the fix doesn't seem work with the new 
> modified macro implementation.

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

[jira] Updated: (VELOCITY-607) Runtime macro rendering very slow in Velocity 1.6-dev (679708) compared to 1.5

[JIRA]

 [ 
https://issues.apache.org/jira/browse/VELOCITY-607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarkko Viinamäki updated VELOCITY-607:
--

Attachment: (was: velocity-1.6-dev-macro-performance-IDEAS-v2.5.patch)

> Runtime macro rendering very slow in Velocity 1.6-dev (679708) compared to 1.5
> --
>
> Key: VELOCITY-607
> URL: https://issues.apache.org/jira/browse/VELOCITY-607
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
> Environment: Maven 2, JUnit, JUnitPerf, JRat, custom testbench: 
> http://www.iki.fi/wyla/velocity/testbench
>Reporter: Jarkko Viinamäki
>Priority: Critical
> Fix For: 1.6
>
> Attachments: velocity-1.5-velocity24-test.PNG, 
> velocity-1.6-head-20080725-velocity24-test.PNG
>
>
> The following test template (see VELOCITY-24):
> ## local macro, not global
> #macro(letter $char)
> This is the letter $char
> #end
> #letter("A")
> #letter("B")
> #letter("C")
> #letter("D")
> #letter("E")
> #letter("F")
> #letter("G")
> #letter("H")
> #letter("I")
> #letter("J")
> #letter("K")
> #letter("L")
> #letter("M")
> #letter("N")
> #letter("O")
> #letter("P")
> #letter("Q")
> #letter("R")
> #letter("S")
> #letter("T")
> #letter("U")
> #letter("V")
> #letter("W")
> #letter("X")
> #letter("Y")
> #letter("Z")
> ---
> Works quickly and correctly with Velocity 1.5 with several concurrent 
> threads. However, 1.6-dev is a LOT slower (even 20x).
> The major performance bottlenecks seem to be:
> RuntimeMacro.render (60% of time)
> VelocimacroFactory.getVelocimacro (20% of time)
> With several threads this test also causes Velocity to throw error(s):
> org.apache.velocity.exception.MacroOverflowException: Exceed maximum 20 macro 
> calls. Call Stack:letter->letter->letter->letter->letter
>   at 
> org.apache.velocity.runtime.VelocimacroFactory.startMacroRendering(VelocimacroFactory.java:179)
>   at 
> org.apache.velocity.runtime.RuntimeInstance.startMacroRendering(RuntimeInstance.java:1693)
>   at 
> org.apache.velocity.runtime.directive.VelocimacroProxy.render(VelocimacroProxy.java:200)
>   at 
> org.apache.velocity.runtime.directive.RuntimeMacro.render(RuntimeMacro.java:230)
>   at 
> org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:178)
>   at 
> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:323)
>   at org.apache.velocity.Template.merge(Template.java:324)
>   at org.apache.velocity.Template.merge(Template.java:232)
>   at 
> org.apache.velocity.test.load.Velocity24Test.testRendering(Velocity24Test.java:51)
> This is related to VELOCITY-297 but the fix doesn't seem work with the new 
> modified macro implementation.

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

[jira] Updated: (VELOCITY-607) Runtime macro rendering very slow in Velocity 1.6-dev (679708) compared to 1.5

[JIRA]

 [ 
https://issues.apache.org/jira/browse/VELOCITY-607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarkko Viinamäki updated VELOCITY-607:
--

Attachment: velocity-1.6-dev-macro-performance-IDEAS-v2.6.patch

Some small additional improvements in patch 2.6. This patch detects if 
ConcurrentHashMap is available and uses it in resourcecache (if the cache is 
configured to be unbounded). Also changed some StringBuffer -> StrBuilder in 
render time segments.

Some minor speed improvements might still be possible in VelocimacroManager and 
VelocimacroFactory (investigate the use of Hashtables and synchronized blocks).

> Runtime macro rendering very slow in Velocity 1.6-dev (679708) compared to 1.5
> --
>
> Key: VELOCITY-607
> URL: https://issues.apache.org/jira/browse/VELOCITY-607
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
> Environment: Maven 2, JUnit, JUnitPerf, JRat, custom testbench: 
> http://www.iki.fi/wyla/velocity/testbench
>Reporter: Jarkko Viinamäki
>Priority: Critical
> Fix For: 1.6
>
> Attachments: velocity-1.5-velocity24-test.PNG, 
> velocity-1.6-dev-macro-performance-IDEAS-v2.6.patch, 
> velocity-1.6-head-20080725-velocity24-test.PNG
>
>
> The following test template (see VELOCITY-24):
> ## local macro, not global
> #macro(letter $char)
> This is the letter $char
> #end
> #letter("A")
> #letter("B")
> #letter("C")
> #letter("D")
> #letter("E")
> #letter("F")
> #letter("G")
> #letter("H")
> #letter("I")
> #letter("J")
> #letter("K")
> #letter("L")
> #letter("M")
> #letter("N")
> #letter("O")
> #letter("P")
> #letter("Q")
> #letter("R")
> #letter("S")
> #letter("T")
> #letter("U")
> #letter("V")
> #letter("W")
> #letter("X")
> #letter("Y")
> #letter("Z")
> ---
> Works quickly and correctly with Velocity 1.5 with several concurrent 
> threads. However, 1.6-dev is a LOT slower (even 20x).
> The major performance bottlenecks seem to be:
> RuntimeMacro.render (60% of time)
> VelocimacroFactory.getVelocimacro (20% of time)
> With several threads this test also causes Velocity to throw error(s):
> org.apache.velocity.exception.MacroOverflowException: Exceed maximum 20 macro 
> calls. Call Stack:letter->letter->letter->letter->letter
>   at 
> org.apache.velocity.runtime.VelocimacroFactory.startMacroRendering(VelocimacroFactory.java:179)
>   at 
> org.apache.velocity.runtime.RuntimeInstance.startMacroRendering(RuntimeInstance.java:1693)
>   at 
> org.apache.velocity.runtime.directive.VelocimacroProxy.render(VelocimacroProxy.java:200)
>   at 
> org.apache.velocity.runtime.directive.RuntimeMacro.render(RuntimeMacro.java:230)
>   at 
> org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:178)
>   at 
> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:323)
>   at org.apache.velocity.Template.merge(Template.java:324)
>   at org.apache.velocity.Template.merge(Template.java:232)
>   at 
> org.apache.velocity.test.load.Velocity24Test.testRendering(Velocity24Test.java:51)
> This is related to VELOCITY-297 but the fix doesn't seem work with the new 
> modified macro implementation.

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

[jira] Commented: (VELOCITY-607) Runtime macro rendering very slow in Velocity 1.6-dev (679708) compared to 1.5

[JIRA]

[ 
https://issues.apache.org/jira/browse/VELOCITY-607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12621306#action_12621306
 ] 

Jarkko Viinamäki commented on VELOCITY-607:
---

The new patch does not require JDK 1.5. It uses dynamic classloading to check 
if the code is running under JRE 1.5+, if it is, it uses ConcurrentHashMap, if 
it is not, it uses synchronized HashMap. See ResourceCacheImpl.

> Runtime macro rendering very slow in Velocity 1.6-dev (679708) compared to 1.5
> --
>
> Key: VELOCITY-607
> URL: https://issues.apache.org/jira/browse/VELOCITY-607
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
> Environment: Maven 2, JUnit, JUnitPerf, JRat, custom testbench: 
> http://www.iki.fi/wyla/velocity/testbench
>Reporter: Jarkko Viinamäki
>Priority: Critical
> Fix For: 1.6
>
> Attachments: velocity-1.5-velocity24-test.PNG, 
> velocity-1.6-dev-macro-performance-IDEAS-v2.6.patch, 
> velocity-1.6-head-20080725-velocity24-test.PNG
>
>
> The following test template (see VELOCITY-24):
> ## local macro, not global
> #macro(letter $char)
> This is the letter $char
> #end
> #letter("A")
> #letter("B")
> #letter("C")
> #letter("D")
> #letter("E")
> #letter("F")
> #letter("G")
> #letter("H")
> #letter("I")
> #letter("J")
> #letter("K")
> #letter("L")
> #letter("M")
> #letter("N")
> #letter("O")
> #letter("P")
> #letter("Q")
> #letter("R")
> #letter("S")
> #letter("T")
> #letter("U")
> #letter("V")
> #letter("W")
> #letter("X")
> #letter("Y")
> #letter("Z")
> ---
> Works quickly and correctly with Velocity 1.5 with several concurrent 
> threads. However, 1.6-dev is a LOT slower (even 20x).
> The major performance bottlenecks seem to be:
> RuntimeMacro.render (60% of time)
> VelocimacroFactory.getVelocimacro (20% of time)
> With several threads this test also causes Velocity to throw error(s):
> org.apache.velocity.exception.MacroOverflowException: Exceed maximum 20 macro 
> calls. Call Stack:letter->letter->letter->letter->letter
>   at 
> org.apache.velocity.runtime.VelocimacroFactory.startMacroRendering(VelocimacroFactory.java:179)
>   at 
> org.apache.velocity.runtime.RuntimeInstance.startMacroRendering(RuntimeInstance.java:1693)
>   at 
> org.apache.velocity.runtime.directive.VelocimacroProxy.render(VelocimacroProxy.java:200)
>   at 
> org.apache.velocity.runtime.directive.RuntimeMacro.render(RuntimeMacro.java:230)
>   at 
> org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:178)
>   at 
> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:323)
>   at org.apache.velocity.Template.merge(Template.java:324)
>   at org.apache.velocity.Template.merge(Template.java:232)
>   at 
> org.apache.velocity.test.load.Velocity24Test.testRendering(Velocity24Test.java:51)
> This is related to VELOCITY-297 but the fix doesn't seem work with the new 
> modified macro implementation.

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

[jira] Updated: (VELOCITY-607) Runtime macro rendering very slow in Velocity 1.6-dev (679708) compared to 1.5

[JIRA]

 [ 
https://issues.apache.org/jira/browse/VELOCITY-607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarkko Viinamäki updated VELOCITY-607:
--

Attachment: velocity-1.6-dev-macro-performance-IDEAS-v2.7.patch

Inspired by Christopher's comment I created a MapFactory which can create Java 
5 concurrent maps if they are available. I implemented it in slightly different 
way though to avoid compile time dependency.

Since there are several maps in VelocimacroFactory and VelocimacroManager, I 
modified those to get their maps from the MapFactory. 

Running on JDK 1.6.0_07 server mode (single core) Velocity 1.6-dev with this 
patch (2.7) was up to 25% faster than 1.5 and I believe the difference grows 
larger when there are more CPUs or concurrent threads.

I'll leave the older 2.6 patch in place since these changes are a bit radical.

I'll stop this optimizing madness and wait for Nathan's input.

> Runtime macro rendering very slow in Velocity 1.6-dev (679708) compared to 1.5
> --
>
> Key: VELOCITY-607
> URL: https://issues.apache.org/jira/browse/VELOCITY-607
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
> Environment: Maven 2, JUnit, JUnitPerf, JRat, custom testbench: 
> http://www.iki.fi/wyla/velocity/testbench
>Reporter: Jarkko Viinamäki
>Priority: Critical
> Fix For: 1.6
>
> Attachments: velocity-1.5-velocity24-test.PNG, 
> velocity-1.6-dev-macro-performance-IDEAS-v2.6.patch, 
> velocity-1.6-dev-macro-performance-IDEAS-v2.7.patch, 
> velocity-1.6-head-20080725-velocity24-test.PNG
>
>
> The following test template (see VELOCITY-24):
> ## local macro, not global
> #macro(letter $char)
> This is the letter $char
> #end
> #letter("A")
> #letter("B")
> #letter("C")
> #letter("D")
> #letter("E")
> #letter("F")
> #letter("G")
> #letter("H")
> #letter("I")
> #letter("J")
> #letter("K")
> #letter("L")
> #letter("M")
> #letter("N")
> #letter("O")
> #letter("P")
> #letter("Q")
> #letter("R")
> #letter("S")
> #letter("T")
> #letter("U")
> #letter("V")
> #letter("W")
> #letter("X")
> #letter("Y")
> #letter("Z")
> ---
> Works quickly and correctly with Velocity 1.5 with several concurrent 
> threads. However, 1.6-dev is a LOT slower (even 20x).
> The major performance bottlenecks seem to be:
> RuntimeMacro.render (60% of time)
> VelocimacroFactory.getVelocimacro (20% of time)
> With several threads this test also causes Velocity to throw error(s):
> org.apache.velocity.exception.MacroOverflowException: Exceed maximum 20 macro 
> calls. Call Stack:letter->letter->letter->letter->letter
>   at 
> org.apache.velocity.runtime.VelocimacroFactory.startMacroRendering(VelocimacroFactory.java:179)
>   at 
> org.apache.velocity.runtime.RuntimeInstance.startMacroRendering(RuntimeInstance.java:1693)
>   at 
> org.apache.velocity.runtime.directive.VelocimacroProxy.render(VelocimacroProxy.java:200)
>   at 
> org.apache.velocity.runtime.directive.RuntimeMacro.render(RuntimeMacro.java:230)
>   at 
> org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:178)
>   at 
> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:323)
>   at org.apache.velocity.Template.merge(Template.java:324)
>   at org.apache.velocity.Template.merge(Template.java:232)
>   at 
> org.apache.velocity.test.load.Velocity24Test.testRendering(Velocity24Test.java:51)
> This is related to VELOCITY-297 but the fix doesn't seem work with the new 
> modified macro implementation.

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

[jira] Commented: (VELOCITY-570) speed improvement of the tokenizer

[JIRA]

[ 
https://issues.apache.org/jira/browse/VELOCITY-570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12622581#action_12622581
 ] 

Jarkko Viinamäki commented on VELOCITY-570:
---

I can confirm that the current SVN head contains a bug which can be fixed by 
the patch Jacob submitted. The bug is critical and causes OutOfMemory error 
when a large template is parsed a couple of times (with caching off):

Running org.apache.velocity.test.issues.RepeatedParsingTest
iteration: 0
iteration: 1
java.lang.OutOfMemoryError: Java heap space
at 
org.apache.velocity.runtime.parser.VelocityCharStream.ExpandBuff(VelocityCharStream.java:
67)
at 
org.apache.velocity.runtime.parser.VelocityCharStream.FillBuff(VelocityCharStream.java:13
1)
at 
org.apache.velocity.runtime.parser.VelocityCharStream.readChar(VelocityCharStream.java:24
6)
at 
org.apache.velocity.runtime.parser.ParserTokenManager.jjMoveNfa_3(ParserTokenManager.java
:2160)

> speed improvement of the tokenizer
> --
>
> Key: VELOCITY-570
> URL: https://issues.apache.org/jira/browse/VELOCITY-570
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
>Affects Versions: 1.4, 1.5, 1.6
> Environment: Tested on FreeBSD 6.2-STABLE and Linux (Debian Etch) on 
> i386.
> Java: JDK 1.5
>Reporter: Ronald Klop
> Fix For: 1.6
>
> Attachments: expandbuff-speedup-reinit-fix.patch, 
> expandbuff-speedup.patch
>
>
> On some large templates (1-4MB) velocity gets very slow. I used JProfiler and 
> found a lot of time is spent in VelocityCharStream.ExpandBuff. It is doing a 
> lot of System.arraycopy.
> The problem is that the size of the buffer is increased linearly in stead of 
> exponentialy.
> I have made a patch which doubles the size of the buffer in stead of 
> incrementing it with the same value.
> In my tests and in JProfiler it is shown that a lot less time is spent in 
> ExpandBuff.

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

[jira] Commented: (VELOCITY-598) Macros within macros are losing the context

[JIRA]

[ 
https://issues.apache.org/jira/browse/VELOCITY-598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12622674#action_12622674
 ] 

Jarkko Viinamäki commented on VELOCITY-598:
---

I'm not sure if this can be classified as a bug. I took a quick peek at the 
Foreach directive code and it seems that the counter ($num) value is saved only 
in the local context. Thus the value is not available for macro invocations if 
the variable is not passed as an argument. This seems logical. There are two 
ways to fix this: 

1) pass $num as an argument to the numMacro call

#macro(numMacro $dum)$dum (numMacro)#end

#macro(outerMacro)
#foreach($num in [1, 2, 3])
from loop body: $num
From Macro: #numMacro($num)
#end
#end
#outerMacro() 


2) use a helper variable.

#macro(numMacro)$dum (numMacro)#end

#macro(outerMacro)
#foreach($num in [1, 2, 3])
#set($dum = $num)
from loop body: $num
From Macro: #numMacro()
#end
#end
#outerMacro() 

I wouldn't advice redefining the macro inside a foreach loop.

> Macros within macros are losing the context
> ---
>
> Key: VELOCITY-598
> URL: https://issues.apache.org/jira/browse/VELOCITY-598
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
>Affects Versions: 1.5
> Environment: velocimacro.permissions.allow.inline.local.scope=true
> velocimacro.permissions.allow.inline=true
> velocimacro.context.localscope=false
> (we can not change this!)
>Reporter: Jörg Gottschling
>Priority: Critical
>
> consider the following test code:
> #foreach($num in [1, 2, 3])
> from loop body: $num
> #macro(numMacro)$num (numMacro)#end
> From Macro: #numMacro()
> #end
> it produces correctly:
> from loop body: 1
> From Macro: 1 (numMacro)
> from loop body: 2
> From Macro: 2 (numMacro)
> from loop body: 3
> From Macro: 3 (numMacro)
> But if you wrap this in a macro again, it fails:
> #macro(outerMacro)
> #foreach($num in [1, 2, 3])
> from loop body: $num
> #macro(numMacro)$num (numMacro)#end
> From Macro: #numMacro()
> #end
> #end
> #outerMacro()
> output:
> from loop body: 1
> From Macro: $num (numMacro)
> from loop body: 2
> From Macro: $num (numMacro)
> from loop body: 3
> From Macro: $num (numMacro)
> That seams to be a bug for me, when considereing the settings above.

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

[jira] Commented: (VELOCITY-558) Allow macros that act as blockDirectives

[JIRA]

[ 
https://issues.apache.org/jira/browse/VELOCITY-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12622998#action_12622998
 ] 

Jarkko Viinamäki commented on VELOCITY-558:
---

This looks a lot like VELOCITY-583

> Allow macros that act as blockDirectives
> 
>
> Key: VELOCITY-558
> URL: https://issues.apache.org/jira/browse/VELOCITY-558
> Project: Velocity
>  Issue Type: Improvement
>  Components: Engine
>Affects Versions: 1.5
> Environment: Windows
>Reporter: Guido Deinhammer
>Priority: Minor
>
> Currently migrating a web project from Oracle's proprietary UIX to Velocity, 
> I found the limitation that macros are always line directives and cannot ave 
> content somewhat limiting.
> I would suggest the following improvement or addition to the macro 
> functionality.
> You should be able to define a blockMacro - maybe with a syntax like this:
> #blockmacro(section $title $open)
> $title
> #if($open)
>   #body
> #end
> 
> #end
> Where #body would render the body of the macro call. The macro call could 
> look like this:
> #section("My Collapsible Section", true)
> sectionContent
> #end
> This allows the macro to render the content only under a certain condition, 
> or it would allow the macro to render the content multiple times. I think 
> this would a lot of flexibilty to macros - it might be an enhancement worth 
> considering for the Summer of Code Google project.

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

[jira] Commented: (VELOCITY-583) BlockMacro support

[JIRA]

[ 
https://issues.apache.org/jira/browse/VELOCITY-583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12623126#action_12623126
 ] 

Jarkko Viinamäki commented on VELOCITY-583:
---

I think the #define directive descibed in VELOCITY-174 can be used to 
accomplish the same thing (use #define to create some custom AST set and pass 
it as an argument to a regular macro). IMHO #define seems more general and 
cleaner solution. Or does this accomplish something that can't be done with 
#define?

> BlockMacro support
> --
>
> Key: VELOCITY-583
> URL: https://issues.apache.org/jira/browse/VELOCITY-583
> Project: Velocity
>  Issue Type: New Feature
>  Components: Engine
>Reporter: Raghu Rajah
> Fix For: 1.6
>
> Attachments: blockmacro.patch
>
>
> Here's the trivial example,
> #blockmacro(html $style)
> 
>  ${yield}
> 
> #end
> Block Macro Result
> #html("color:red")
> Raghu
> #end
> Full discussion on thread: http://tinyurl.com/ytq3k4

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

[jira] Commented: (VELOCITY-174) For consideration: #define()...#end directive to define a block of VTL as a reference

[JIRA]

[ 
https://issues.apache.org/jira/browse/VELOCITY-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12623127#action_12623127
 ] 

Jarkko Viinamäki commented on VELOCITY-174:
---

I think #define is at least very useful and it can be used to build 
blockmacro-type functionality. It might be necessary though to rethrow at least 
MethodInvocationException and RuntimeException in toString-method of the 
BlockDefNode.

> For consideration: #define()...#end directive to define a block of VTL as a 
> reference
> -
>
> Key: VELOCITY-174
> URL: https://issues.apache.org/jira/browse/VELOCITY-174
> Project: Velocity
>  Issue Type: Improvement
>  Components: Engine
>Affects Versions: 1.3.1
> Environment: Operating System: All
> Platform: All
>Reporter: Andrew Tetlaw
>Priority: Minor
> Fix For: 1.6
>
> Attachments: Define.java, Extends.java
>
>
> * Proposal:
> #define( $block_ref )
>  ## any VTL / text content here
>  ... 
> #end
> then you can use it like a reference:
>  $!block_ref  / #if( $block_ref ).. #end / and so on
> * Justification:
> 1. Allows template designer to use a more efficient inside -> out approach
> (similar to Nathan's VelocityLayoutServlet)
> 2. Keeps macro framework separate (the app developer can still disallow inline
> macros)
> 3. #macros to return blocks of VTL cannot be used like silent references or in
> other directives (like #if)
> 4. The multi-line #set proposal requires a quoted value. A #define() block can
> contain anything (without the need to escape quotes for example).
> 5. #define() blocks are proxied (like #macros) and thus change according to 
> the
> context after they are defined, something a normal $reference or #set can't 
> do.
> 7. Can improve template management by reducing number of unique template 
> components
> 8. Can improve template security/errors by reducing the need for bottom tier
> template makers to worry about generic layout code and visa-versa.
> 9. Merges the strengths of #macros and $references = best of both worlds
> * Usage Example: Custom HTML forms:
> template 1. : document_type_1_custom_form_body.vm
> 
> #define( $custom_form_body )
>   ## unique form fields here
> #end
> #parse("main_form_layout.vm")
> 
> template 2 : main_form_layout.vm
> 
> #define( $custom_page_body )
> 
> ## common form fields here
> $!custom_form_body
> 
> 
> #end
> #parse("main_page_layout.vm")
> 
> template 2 : main_page_layout.vm
> 
> 
> ## common page layout html here
> $!custom_page_body
> 
> 
> If the #define() directive was not available a template designer would need to
> do this:
> template 1. : document_type_1_custom_form_body.vm
> 
> #parse("main_page_layout_header.vm")
> #parse("main_form_layout_header.vm")
>  ## unique form fields here
> #parse("main_form_layout_header.vm")
> #parse("main_page_layout_header.vm")
> 
> Not only is the same output achieved with fewer #parse() directives (3 v 5), 
> the
> unique templates are fewer and easier to manage. Template designers can make
> many document_type_X templates and need only to define the reference
> $custom_form_body and not worry about the overall page layout. Custom parts of
> the page are also only optionally required now; the main template can test 
> for a
> reference and display a default block if it isn't defined.

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

[jira] Created: (VELOCITY-612) Support for #break directive inside foreach loops (includes a patch)

[JIRA]

Support for #break directive inside foreach loops (includes a patch)


 Key: VELOCITY-612
 URL: https://issues.apache.org/jira/browse/VELOCITY-612
 Project: Velocity
  Issue Type: Improvement
  Components: Engine
Reporter: Jarkko Viinamäki
Priority: Minor
 Fix For: 1.6


Here's a small patch that adds support for #break directive that can be used to 
break foreach-loops.

Catch: #break does not verify that it is inside a foreach loop. If it is not, a 
RuntimeException of type BreakException is thrown during rendering and not 
caught properly. Testcases are also quite laughable but the directive seems to 
work OK.

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

[jira] Updated: (VELOCITY-612) Support for #break directive inside foreach loops (includes a patch)

[JIRA]

 [ 
https://issues.apache.org/jira/browse/VELOCITY-612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarkko Viinamäki updated VELOCITY-612:
--

Attachment: velocity-1.6-dev-break-directive.patch

> Support for #break directive inside foreach loops (includes a patch)
> 
>
> Key: VELOCITY-612
> URL: https://issues.apache.org/jira/browse/VELOCITY-612
> Project: Velocity
>  Issue Type: Improvement
>  Components: Engine
>Reporter: Jarkko Viinamäki
>Priority: Minor
> Fix For: 1.6
>
> Attachments: velocity-1.6-dev-break-directive.patch
>
>
> Here's a small patch that adds support for #break directive that can be used 
> to break foreach-loops.
> Catch: #break does not verify that it is inside a foreach loop. If it is not, 
> a RuntimeException of type BreakException is thrown during rendering and not 
> caught properly. Testcases are also quite laughable but the directive seems 
> to work OK.

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

[jira] Updated: (VELOCITY-355) lost '#'s inside #literal()/#end

[JIRA]

 [ 
https://issues.apache.org/jira/browse/VELOCITY-355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarkko Viinamäki updated VELOCITY-355:
--

Attachment: velocity-1.6-dev-355-perf.patch

Nathan have you checked if this change has any significant impact on 
performance? 

NodeUtils.tokenLiteral looks a bit heavy and since it is now called in 
SimpleNode, it is used in many parsed nodes. If the bug is related to _only_ 
#literal directive and there's a performance penalty, would it be possible to 
modify just Literal.init instead like Will suggested? The fix works if we use a 
modified literal() method in Literal class.

Here's a small patch I used to test this.

> lost '#'s inside #literal()/#end
> 
>
> Key: VELOCITY-355
> URL: https://issues.apache.org/jira/browse/VELOCITY-355
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
>Affects Versions: 1.4
> Environment: Operating System: All
> Platform: All
>Reporter: Geoffrey Lowney
> Fix For: 1.6
>
> Attachments: velocity-1.6-dev-355-perf.patch
>
>
> I am using VTL (with VPP) to customize a portion of a Perl script. Since Perl
> code has a lot of dollar signs, I am using #literal()/#end to prevent Velocity
> from processing most of the file.  What I find is that single '#' characters
> that are not followed by alpha text are removed (inside #literal()/#end).
> For example:
>   #literal()
>   #!/usr/bin/perl
>   #end
> becomes:
>   !/usr/bin/perl
> I've tried things like escaping the '#' ('\#') but that leaves the backslash
> ('\#!/usr/bin/perl' becomes '\!/usr/bin/perl').  Nothing seems to work.
> I can use a #set to define a variable with the value '#!/usr/bin/perl', but I
> was hoping I would not have to.  It also doesn't help with other single #'s in
> the file (like Perl comments).  For those I have had to double up the hashes.
> I'd be happy to try patching the Velocity source, but I had trouble making 
> heads
> or tails of the parser engine?

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

[jira] Updated: (VELOCITY-544) BooleanPropertyExecutor refers to primitive boolean not object Boolean

[JIRA]

 [ 
https://issues.apache.org/jira/browse/VELOCITY-544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarkko Viinamäki updated VELOCITY-544:
--

Attachment: velocity-1.6-dev-544-patch-and-testcase.patch

I can confirm that there's a bug in current SVN head. 

Velocity fails to detect methods of type public Boolean is(). The fix 
suggested in this issue works so I included that and a test case in the 
attached patch.

> BooleanPropertyExecutor refers to primitive boolean not object Boolean
> --
>
> Key: VELOCITY-544
> URL: https://issues.apache.org/jira/browse/VELOCITY-544
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
>Affects Versions: 1.5
>Reporter: Will Glass-Husain
>Priority: Minor
> Attachments: velocity-1.6-dev-544-patch-and-testcase.patch
>
>
> note from Will: not sure if this is an actual bug or just a confusion re: the 
> source.  need to investigate.
> an example of a user-visible symptom would be helpful.  see Christopher's 
> note.
> -- Forwarded message --
> From: Adam Bishop (DSLWN) <[EMAIL PROTECTED]>
> Date: May 3, 2007 10:15 PM
> Subject: BooleanPropertyExecutor bug
> To: dev@velocity.apache.org
> getMethod().getReturnType() != Boolean.TYPE
> returns true if the method return type is Boolean rather than boolean.
> (i.e. it doesn't like the Boolean class, just the boolean primitive)
> the line should be
> getMethod().getReturnType() != Boolean.TYPE &&
> getMethod().getReturnType()!=Boolean.class
> bug exists in 1.3.1 and 1.5
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> -- Forwarded message --
> From: Christopher Schultz <[EMAIL PROTECTED]>
> Date: May 4, 2007 9:59 AM
> Subject: Re: BooleanPropertyExecutor bug
> To: Velocity Developers List 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> All,
> I haven't looked at the code, but introspection often has special cases
> for primitive types, whereas their wrapper types (java.lang.Boolean, in
> this case) are handled generically as Objects.
> Are we sure that java.lang.Boolean.class is appropriate to check in this
> case?
> Adam did not provide an example of how to demonstrate the existence of
> the bug... just an assertion that the code was not sufficient.
> - -chris

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

[jira] Updated: (VELOCITY-657) $velocityHasNext not working properly (returns true even if iterator does not have next value)

[JIRA]

 [ 
https://issues.apache.org/jira/browse/VELOCITY-657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarkko Viinamäki updated VELOCITY-657:
--

Attachment: velocity-657-testcase.patch

> $velocityHasNext not working properly (returns true even if iterator does not 
> have next value)
> --
>
> Key: VELOCITY-657
> URL: https://issues.apache.org/jira/browse/VELOCITY-657
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
>Affects Versions: 1.6
>Reporter: Dominik Marks
>Priority: Minor
> Attachments: velocity-657-testcase.patch
>
>
> Using the new "velocityHasNext" feature in loops does not work as expected.
> When using the following excerpt:
> #foreach ($value in $element.values)
>  $value 
>  #if( $velocityHasNext )
>   SEPARATOR
>  #end
> #end
> and having $element.values as e.g. "test1", "test2", "test3"
> I get
> test1 SEPARATOR test2 SEPARATOR test3 SEPARATOR
> but I would expect
> test1 SEPARATOR test2 SEPARATOR test3
> When looking into the source code, I see the following in 
> org.apache.velocity.runtime.directive.Foreach.render():
> while (!maxNbrLoopsExceeded && i.hasNext())
> {
> // TODO: JDK 1.5+ -> Integer.valueOf()
> put(context, counterName , new Integer(counter));
> put(context, hasNextName, Boolean.valueOf(i.hasNext()));
> Object value = i.next();
> put(context, elementKey, value);
>   
> }
> Isn't this the wrong order of instructions?
> I would expect:
> Object value = i.next();
> put(context, hasNextName, Boolean.valueOf(i.hasNext()));
> So that the $velocityHasNext variable will be filled with the "hasNext" of 
> the follow-up iteration and not with the "hasNext" of the current iteration 
> (which will always be true, otherwise the loop has finished before).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] Commented: (VELOCITY-657) $velocityHasNext not working properly (returns true even if iterator does not have next value)

[JIRA]

[ 
https://issues.apache.org/jira/browse/VELOCITY-657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12658973#action_12658973
 ] 

Jarkko Viinamäki commented on VELOCITY-657:
---

It seems that this has been fixed in the trunk (on Dec-14) but the 1.6.1 
release contains this bug. There should always be JUnit tests for new 
features...

> $velocityHasNext not working properly (returns true even if iterator does not 
> have next value)
> --
>
> Key: VELOCITY-657
> URL: https://issues.apache.org/jira/browse/VELOCITY-657
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
>Affects Versions: 1.6
>Reporter: Dominik Marks
>Priority: Minor
> Attachments: velocity-657-testcase.patch
>
>
> Using the new "velocityHasNext" feature in loops does not work as expected.
> When using the following excerpt:
> #foreach ($value in $element.values)
>  $value 
>  #if( $velocityHasNext )
>   SEPARATOR
>  #end
> #end
> and having $element.values as e.g. "test1", "test2", "test3"
> I get
> test1 SEPARATOR test2 SEPARATOR test3 SEPARATOR
> but I would expect
> test1 SEPARATOR test2 SEPARATOR test3
> When looking into the source code, I see the following in 
> org.apache.velocity.runtime.directive.Foreach.render():
> while (!maxNbrLoopsExceeded && i.hasNext())
> {
> // TODO: JDK 1.5+ -> Integer.valueOf()
> put(context, counterName , new Integer(counter));
> put(context, hasNextName, Boolean.valueOf(i.hasNext()));
> Object value = i.next();
> put(context, elementKey, value);
>   
> }
> Isn't this the wrong order of instructions?
> I would expect:
> Object value = i.next();
> put(context, hasNextName, Boolean.valueOf(i.hasNext()));
> So that the $velocityHasNext variable will be filled with the "hasNext" of 
> the follow-up iteration and not with the "hasNext" of the current iteration 
> (which will always be true, otherwise the loop has finished before).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] Commented: (VELOCITY-648) Non zero resource cache size slower

[JIRA]

[ 
https://issues.apache.org/jira/browse/VELOCITY-648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12658978#action_12658978
 ] 

Jarkko Viinamäki commented on VELOCITY-648:
---

It's very very difficult to create a bounded map that performs as well as the 
ConcurrentHashMap - especially using the LRU algorithm. 

Should we make default value for defaultcache 0 so that ConcurrentHashMap would 
kick in by default? If the user then runs into OutOfMemory problems (too many 
templates in memory), he could change to bounded LRUMap. This might be ok since 
template memory consumption has decreased significantly since 1.5. Of course 
this might surprise many users who expect the same default behaviour that was 
in earlier releases.

> Non zero resource cache size slower
> ---
>
> Key: VELOCITY-648
> URL: https://issues.apache.org/jira/browse/VELOCITY-648
> Project: Velocity
>  Issue Type: Improvement
>  Components: Engine
>Reporter: Byron Foster
> Fix For: 1.7
>
>
> In performance testing I found that setting the 
> resource.manager.defaultcache.size property to 0 increases performance by 
> about 30%.   The reason for this is that when the cache size is set to 0 
> Velocity uses the java.util.concurrent.ConcurrentHashMap container which 
> provides better thread concurrency.  when the cache size is set to a non-zero 
> value Velocity uses the org.apache.commons.collections.map.LRUMap container, 
> which provides poor concurrency.  The problem is that It's unclear if there 
> is a container that provides both good concurrency, and has a max size 
> setting.
> The default cache size is 89, which uses the slower LRUMap, and the end user 
> is non the wiser.  The best solution would be to find a container that can be 
> used in both cases that performs as well as the ConcurrentHashMap, otherwise 
> a discussion in the documentation is probably warranted.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] Created: (VELOCITY-658) $velocityHasNext does not work in nested loops

[JIRA]

$velocityHasNext does not work in nested loops
--

 Key: VELOCITY-658
 URL: https://issues.apache.org/jira/browse/VELOCITY-658
 Project: Velocity
  Issue Type: Bug
  Components: Engine
Affects Versions: 1.6, 1.6.1
Reporter: Jarkko Viinamäki
Priority: Minor


With this test case:

assertEvalEquals("test1 (a1;a2;a3)-test2 (a1;a2;a3)-test3 (a1;a2;a3)-test4 
(a1;a2;a3)", 
"#foreach ($value in $list)$value (#foreach ($val in $list2)$val#if( 
$velocityHasNext );#end#end)#if( $velocityHasNext )-#end#end"); 

Velocity 1.6.1 (or current head) fails because the "hasNext" flag status of the 
outer foreach loop gets overwritten by the nested foreach loop. To fix this we 
need to save the status of the hasNext flag in Foreach directive just like we 
save the value of the counter.

This bug is related to VELOCITY-657 but is a separate bug. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] Updated: (VELOCITY-658) $velocityHasNext does not work in nested loops

[JIRA]

 [ 
https://issues.apache.org/jira/browse/VELOCITY-658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarkko Viinamäki updated VELOCITY-658:
--

Attachment: velocity-hasNext-bug.patch

Testcase and a patch that fixes this bug.

> $velocityHasNext does not work in nested loops
> --
>
> Key: VELOCITY-658
> URL: https://issues.apache.org/jira/browse/VELOCITY-658
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
>Affects Versions: 1.6, 1.6.1
>Reporter: Jarkko Viinamäki
>Priority: Minor
> Attachments: velocity-hasNext-bug.patch
>
>
> With this test case:
> assertEvalEquals("test1 (a1;a2;a3)-test2 (a1;a2;a3)-test3 (a1;a2;a3)-test4 
> (a1;a2;a3)", 
> "#foreach ($value in $list)$value (#foreach ($val in $list2)$val#if( 
> $velocityHasNext );#end#end)#if( $velocityHasNext )-#end#end"); 
> Velocity 1.6.1 (or current head) fails because the "hasNext" flag status of 
> the outer foreach loop gets overwritten by the nested foreach loop. To fix 
> this we need to save the status of the hasNext flag in Foreach directive just 
> like we save the value of the counter.
> This bug is related to VELOCITY-657 but is a separate bug. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] Resolved: (VELOCITY-658) $velocityHasNext does not work in nested loops

[JIRA]

 [ 
https://issues.apache.org/jira/browse/VELOCITY-658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarkko Viinamäki resolved VELOCITY-658.
---

Resolution: Fixed

Thanks. Marking this as resolved.

> $velocityHasNext does not work in nested loops
> --
>
> Key: VELOCITY-658
> URL: https://issues.apache.org/jira/browse/VELOCITY-658
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
>Affects Versions: 1.6, 1.6.1
>Reporter: Jarkko Viinamäki
>Priority: Minor
> Attachments: velocity-hasNext-bug.patch
>
>
> With this test case:
> assertEvalEquals("test1 (a1;a2;a3)-test2 (a1;a2;a3)-test3 (a1;a2;a3)-test4 
> (a1;a2;a3)", 
> "#foreach ($value in $list)$value (#foreach ($val in $list2)$val#if( 
> $velocityHasNext );#end#end)#if( $velocityHasNext )-#end#end"); 
> Velocity 1.6.1 (or current head) fails because the "hasNext" flag status of 
> the outer foreach loop gets overwritten by the nested foreach loop. To fix 
> this we need to save the status of the hasNext flag in Foreach directive just 
> like we save the value of the counter.
> This bug is related to VELOCITY-657 but is a separate bug. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] Reopened: (VELOCITY-658) $velocityHasNext does not work in nested loops

[JIRA]

 [ 
https://issues.apache.org/jira/browse/VELOCITY-658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarkko Viinamäki reopened VELOCITY-658:
---


> $velocityHasNext does not work in nested loops
> --
>
> Key: VELOCITY-658
> URL: https://issues.apache.org/jira/browse/VELOCITY-658
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
>Affects Versions: 1.6, 1.6.1
>Reporter: Jarkko Viinamäki
>Priority: Minor
> Fix For: 1.7
>
> Attachments: velocity-hasNext-bug.patch
>
>
> With this test case:
> assertEvalEquals("test1 (a1;a2;a3)-test2 (a1;a2;a3)-test3 (a1;a2;a3)-test4 
> (a1;a2;a3)", 
> "#foreach ($value in $list)$value (#foreach ($val in $list2)$val#if( 
> $velocityHasNext );#end#end)#if( $velocityHasNext )-#end#end"); 
> Velocity 1.6.1 (or current head) fails because the "hasNext" flag status of 
> the outer foreach loop gets overwritten by the nested foreach loop. To fix 
> this we need to save the status of the hasNext flag in Foreach directive just 
> like we save the value of the counter.
> This bug is related to VELOCITY-657 but is a separate bug. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] Resolved: (VELOCITY-658) $velocityHasNext does not work in nested loops

[JIRA]

 [ 
https://issues.apache.org/jira/browse/VELOCITY-658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarkko Viinamäki resolved VELOCITY-658.
---

   Resolution: Fixed
Fix Version/s: 1.7

> $velocityHasNext does not work in nested loops
> --
>
> Key: VELOCITY-658
> URL: https://issues.apache.org/jira/browse/VELOCITY-658
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
>Affects Versions: 1.6, 1.6.1
>Reporter: Jarkko Viinamäki
>Priority: Minor
> Fix For: 1.7
>
> Attachments: velocity-hasNext-bug.patch
>
>
> With this test case:
> assertEvalEquals("test1 (a1;a2;a3)-test2 (a1;a2;a3)-test3 (a1;a2;a3)-test4 
> (a1;a2;a3)", 
> "#foreach ($value in $list)$value (#foreach ($val in $list2)$val#if( 
> $velocityHasNext );#end#end)#if( $velocityHasNext )-#end#end"); 
> Velocity 1.6.1 (or current head) fails because the "hasNext" flag status of 
> the outer foreach loop gets overwritten by the nested foreach loop. To fix 
> this we need to save the status of the hasNext flag in Foreach directive just 
> like we save the value of the counter.
> This bug is related to VELOCITY-657 but is a separate bug. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] Commented: (VELOCITY-655) Macro parameter value can't be changed inside a macro

[JIRA]

[ 
https://issues.apache.org/jira/browse/VELOCITY-655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12659453#action_12659453
 ] 

Jarkko Viinamäki commented on VELOCITY-655:
---

If this has been fixed, should it be marked as resolved?

> Macro parameter value can't be changed inside a macro
> -
>
> Key: VELOCITY-655
> URL: https://issues.apache.org/jira/browse/VELOCITY-655
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
>Affects Versions: 1.6
>Reporter: Martin Schwaiger
> Attachments: VELOCITY-655_ParameterProblem.vm
>
>
> I've detected a problem when changing parameter values inside a macro using 
> velocity engine version 1.6.
> In my use case I have to lower the input string first and then do further 
> processing.
> With version 1.5 of the velocity engine there were no problems to implement 
> this use case.
> Here is an example which shows the differences between version 1.5 and 1.6:
> Template-Code:
> {code}
> #macro(testMacro $x)
> #set ($x = $x.toLowerCase())
> #set ($y = $x.toLowerCase())
> x=$x
> y=$y
> #end
> #testMacro('ABCDEFGHIJKLMNOPQRSTUVWXYZ-Testcase1')
> #testMacro("ABCDEFGHIJKLMNOPQRSTUVWXYZ-Testcase2")
> {code}
> Result with Velocity Engine 1.5:
> x=abcdefghijklmnopqrstuvwxyz-testcase1
> y=abcdefghijklmnopqrstuvwxyz-testcase1
> x=abcdefghijklmnopqrstuvwxyz-testcase2
> y=abcdefghijklmnopqrstuvwxyz-testcase2
> Result with Velocity Engine 1.6:
> x=ABCDEFGHIJKLMNOPQRSTUVWXYZ-Testcase1
> y=abcdefghijklmnopqrstuvwxyz-testcase1
> x=ABCDEFGHIJKLMNOPQRSTUVWXYZ-Testcase2
> y=abcdefghijklmnopqrstuvwxyz-testcase2

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] Commented: (VELOCITY-657) $velocityHasNext not working properly (returns true even if iterator does not have next value)

[JIRA]

[ 
https://issues.apache.org/jira/browse/VELOCITY-657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12659646#action_12659646
 ] 

Jarkko Viinamäki commented on VELOCITY-657:
---

Since this has been fixed in the trunk I think we can mark this as resolved.

> $velocityHasNext not working properly (returns true even if iterator does not 
> have next value)
> --
>
> Key: VELOCITY-657
> URL: https://issues.apache.org/jira/browse/VELOCITY-657
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
>Affects Versions: 1.6
>Reporter: Dominik Marks
>Priority: Minor
> Attachments: velocity-657-testcase.patch
>
>
> Using the new "velocityHasNext" feature in loops does not work as expected.
> When using the following excerpt:
> #foreach ($value in $element.values)
>  $value 
>  #if( $velocityHasNext )
>   SEPARATOR
>  #end
> #end
> and having $element.values as e.g. "test1", "test2", "test3"
> I get
> test1 SEPARATOR test2 SEPARATOR test3 SEPARATOR
> but I would expect
> test1 SEPARATOR test2 SEPARATOR test3
> When looking into the source code, I see the following in 
> org.apache.velocity.runtime.directive.Foreach.render():
> while (!maxNbrLoopsExceeded && i.hasNext())
> {
> // TODO: JDK 1.5+ -> Integer.valueOf()
> put(context, counterName , new Integer(counter));
> put(context, hasNextName, Boolean.valueOf(i.hasNext()));
> Object value = i.next();
> put(context, elementKey, value);
>   
> }
> Isn't this the wrong order of instructions?
> I would expect:
> Object value = i.next();
> put(context, hasNextName, Boolean.valueOf(i.hasNext()));
> So that the $velocityHasNext variable will be filled with the "hasNext" of 
> the follow-up iteration and not with the "hasNext" of the current iteration 
> (which will always be true, otherwise the loop has finished before).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] Commented: (VELOCITY-661) Parsing errors on content inside #literal() #end block

[JIRA]

[ 
https://issues.apache.org/jira/browse/VELOCITY-661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12659885#action_12659885
 ] 

Jarkko Viinamäki commented on VELOCITY-661:
---

I think Velocity should not interpret anything inside the literal directive. In 
fact, if you look at the documentation, that is the behaviour one  would 
naturally expect:

"the #literal script element allows the template designer to easily use large 
chunks of *uninterpreted* content in VTL code"
http://velocity.apache.org/engine/devel/user-guide.html#stringliterals

What would be an easy way to change the literal directive so that Velocity does 
not interpret anything inside it?

> Parsing errors on content inside #literal() #end block
> --
>
> Key: VELOCITY-661
> URL: https://issues.apache.org/jira/browse/VELOCITY-661
> Project: Velocity
>  Issue Type: Improvement
>  Components: Engine
>Affects Versions: 1.6.1
> Environment: ALL
>Reporter: ND
>
> I have some velocity templates that include quit some javascript. Inside the 
> javascript a javascrip template engine is used which also uses ${varname}
> Escaping each occurance would make the code rather unreable, so to prevent 
> velocity from parsing the javascript code, I put a #literal() around it.
> However, velocity still PARSES the contents of this block, which of course 
> results in parsing exceptions.
> My feeling with "literal" is that it is completely UNINTERPRETED content?
> This SHOULD work:
> #literal()
>  var myId = 'someID';
>  $('#test).append($.template('').apply({myId: myId}));
> #end

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] Updated: (VELOCITY-661) Parsing errors on content inside #literal() #end block

[JIRA]

 [ 
https://issues.apache.org/jira/browse/VELOCITY-661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarkko Viinamäki updated VELOCITY-661:
--

Attachment: velocity-661-v1.0.patch

OK. Here's my attempt to fix this issue. 

This patch introduces a new token type which I call "Textblock". Textblocks can 
be marked like this:

#% here you can have any text, characters etc. %#

Velocity will not attempt to parse anything between "#% " and " %#" and will 
output content between these tokens as such. Note that one whitespace is part 
of each token.

With this feature it is easy to deal with issues described e.g. in VELOCITY-584

Reasons for selecting this token format:
1. It's short and thus easy to use.
2. It is quite unlikely that you need to have string " %#" inside the area you 
want to "escape" with a Textblock. Thus there is no need for a custom end token 
(which would have been tricky to implement). Note that you can have %# inside 
the area as long as it doesn't have whitespace in front of it.

This patch also includes some performance tweaks made to the parser:
1. Transformation StringBuffer -> StrBuilder is done with Ant script after the 
generation.
2. Parser state is stored using a custom inner class instead of Hashtable which 
wastes space.

Note that I'm a total newbie with JavaCC (I took a closer look at it today for 
the first time) so the parser might not be as efficient as possible. I had to 
use the JavaCC MORE feature when in IN_TEXTBLOCK mode. I'm not sure if this is 
the only way.

NOTICE! You must use "ant parser" command to process the Parser.jjt which then 
generates Parser.java etc. I didn't include the generated files in this patch 
since TortoiseSVN complained something about invalid linefeeds. I noticed that 
JavaCC 4.2 is incompatible with existing classes. JavaCC 4.0 worked OK.

Tweaks to the build.xml:
1. Now it's possible to execute just one Test Case by defining the test case 
name:
ant -Dtestcase=org.apache.velocity.test.TextblockTestCase test

This makes debugging a lot faster.

2. Generated ParserTokenManager is tweaked to use StrBuilder by simple search & 
replace.

> Parsing errors on content inside #literal() #end block
> --
>
> Key: VELOCITY-661
> URL: https://issues.apache.org/jira/browse/VELOCITY-661
> Project: Velocity
>  Issue Type: Improvement
>  Components: Engine
>Affects Versions: 1.6.1
> Environment: ALL
>Reporter: ND
> Attachments: velocity-661-v1.0.patch
>
>
> I have some velocity templates that include quit some javascript. Inside the 
> javascript a javascrip template engine is used which also uses ${varname}
> Escaping each occurance would make the code rather unreable, so to prevent 
> velocity from parsing the javascript code, I put a #literal() around it.
> However, velocity still PARSES the contents of this block, which of course 
> results in parsing exceptions.
> My feeling with "literal" is that it is completely UNINTERPRETED content?
> This SHOULD work:
> #literal()
>  var myId = 'someID';
>  $('#test).append($.template('').apply({myId: myId}));
> #end

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] Commented: (VELOCITY-664) Unnecessary double storing of template text

[JIRA]

[ 
https://issues.apache.org/jira/browse/VELOCITY-664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12660594#action_12660594
 ] 

Jarkko Viinamäki commented on VELOCITY-664:
---

I don't like this change. 

Although this change may decrease memory usage a bit (did you measure how 
much?) it creates a new performance penalty. This is because 
java.io.Writer.write(String) does internally String.getChars call which 
requires System.arrayCopy.

That is certainly slower than doing direct java.io.Writer(char[]) which has no 
overhead.

Strings are stored as char arrays for performance reasons.

> Unnecessary double storing of template text
> ---
>
> Key: VELOCITY-664
> URL: https://issues.apache.org/jira/browse/VELOCITY-664
> Project: Velocity
>  Issue Type: Improvement
>  Components: Engine
>Reporter: Byron Foster
>
> ASTText makes a copy of the token image and uses the copy to render.  This 
> means that ASTText keeps two copies of the text.  In the majority of cases 
> ASTText can use the token image.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] Commented: (VELOCITY-661) Parsing errors on content inside #literal() #end block

[JIRA]

[ 
https://issues.apache.org/jira/browse/VELOCITY-661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12660597#action_12660597
 ] 

Jarkko Viinamäki commented on VELOCITY-661:
---

Thanks for the comments. I don't have the energy to start building separate 
patch files of those changes right now. Nathan, I'll get back to you about 
those CLA issues.

I experimented with different token types and indeed at one point I considered 
using "#%% " (forgot to update the JavaDoc) but it's not as simple as "#% " 
which I find better. It's consistent with the regular comment format #* this is 
a comment *#

If you need to include " %#" (notice that it has to contain the leading 
whitespace to cause "problems") inside #% block %#, then you can easily work 
around it e.g. by dividing the textblock in half:

#% this is the first part %# %# #% this is the second part %#

will result in
this is the first part %# this is the second part

Note that it's perfectly ok to write: #% this is a comment with stuff%# in it 
%# 

I'd guess that " %#" is unlikely enough. Anyway, it's a matter of taste and 
both work. I just like simplicity. :)


> Parsing errors on content inside #literal() #end block
> ------
>
> Key: VELOCITY-661
> URL: https://issues.apache.org/jira/browse/VELOCITY-661
> Project: Velocity
>  Issue Type: Improvement
>  Components: Engine
>Affects Versions: 1.6.1
> Environment: ALL
>Reporter: ND
> Attachments: velocity-661-v1.0.patch
>
>
> I have some velocity templates that include quit some javascript. Inside the 
> javascript a javascrip template engine is used which also uses ${varname}
> Escaping each occurance would make the code rather unreable, so to prevent 
> velocity from parsing the javascript code, I put a #literal() around it.
> However, velocity still PARSES the contents of this block, which of course 
> results in parsing exceptions.
> My feeling with "literal" is that it is completely UNINTERPRETED content?
> This SHOULD work:
> #literal()
>  var myId = 'someID';
>  $('#test).append($.template('').apply({myId: myId}));
> #end

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] Commented: (VELOCITY-661) Parsing errors on content inside #literal() #end block

[JIRA]

[ 
https://issues.apache.org/jira/browse/VELOCITY-661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12660618#action_12660618
 ] 

Jarkko Viinamäki commented on VELOCITY-661:
---

OTOH, I started to think how likely is it that some templates of existing 
applications contain the "#% " pattern? This is more problematic than the end 
token since this token starts the textblock and may break rendering.

So #%% %%# would be definitely a safer solution although it's longer and not so 
pretty. Heh. So I ended up advocating both approaches. Technically both are 
equally easy to implement and there should not be difference in performance 
either.

I trust Nathan will make the right choice.

> Parsing errors on content inside #literal() #end block
> --
>
> Key: VELOCITY-661
>     URL: https://issues.apache.org/jira/browse/VELOCITY-661
> Project: Velocity
>  Issue Type: Improvement
>  Components: Engine
>Affects Versions: 1.6.1
> Environment: ALL
>Reporter: ND
> Attachments: velocity-661-v1.0.patch
>
>
> I have some velocity templates that include quit some javascript. Inside the 
> javascript a javascrip template engine is used which also uses ${varname}
> Escaping each occurance would make the code rather unreable, so to prevent 
> velocity from parsing the javascript code, I put a #literal() around it.
> However, velocity still PARSES the contents of this block, which of course 
> results in parsing exceptions.
> My feeling with "literal" is that it is completely UNINTERPRETED content?
> This SHOULD work:
> #literal()
>  var myId = 'someID';
>  $('#test).append($.template('').apply({myId: myId}));
> #end

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] Commented: (VELOCITY-664) Unnecessary double storing of template text

[JIRA]

[ 
https://issues.apache.org/jira/browse/VELOCITY-664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12660792#action_12660792
 ] 

Jarkko Viinamäki commented on VELOCITY-664:
---

Hmm now I see this code in the trunk:

public Object init( InternalContextAdapter context, Object data)
throws TemplateInitException
{
// In case init gets called more then once.
if (ctext == null)
{
Token t = getFirstToken();
// In most cases tokenLiteral() will return back t.image, we want 
to use t.image directly
// and not a copy because otherwise this would mean all text nodes 
are stored twice.
ctext = NodeUtils.tokenLiteral(getFirstToken()).toCharArray();
}
return data;
}

The // comment does not make sense anymore, there is one needless call to 
getFirstToken() and I don't see where you null out the token. And if the token 
is nulled, I think we need to override literal() because that method will break 
if the first token is null.

Are there situations where some AST nodes are actually initialized more than 
once?

> Unnecessary double storing of template text
> ---
>
> Key: VELOCITY-664
> URL: https://issues.apache.org/jira/browse/VELOCITY-664
> Project: Velocity
>  Issue Type: Improvement
>  Components: Engine
>Reporter: Byron Foster
>
> ASTText makes a copy of the token image and uses the copy to render.  This 
> means that ASTText keeps two copies of the text.  In the majority of cases 
> ASTText can use the token image.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] Commented: (VELOCITY-661) Parsing errors on content inside #literal() #end block

[JIRA]

[ 
https://issues.apache.org/jira/browse/VELOCITY-661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12660908#action_12660908
 ] 

Jarkko Viinamäki commented on VELOCITY-661:
---

This is a bit tricky issue.

#%%this does not work%%#  (the parser chokes with #%%#%%#)

#!!this does not work either!!#

For some reason #((this works))# and even #((#))# this works too.

So if you replace %% with (( then the whitespace is not needed in the token and 
this works too:

#((
block
))#

I'm not sure why %% and !! don't work.

> Parsing errors on content inside #literal() #end block
> --
>
> Key: VELOCITY-661
> URL: https://issues.apache.org/jira/browse/VELOCITY-661
> Project: Velocity
>  Issue Type: Improvement
>  Components: Engine
>Affects Versions: 1.6.1
> Environment: ALL
>Reporter: ND
> Attachments: velocity-661-v1.0.patch
>
>
> I have some velocity templates that include quit some javascript. Inside the 
> javascript a javascrip template engine is used which also uses ${varname}
> Escaping each occurance would make the code rather unreable, so to prevent 
> velocity from parsing the javascript code, I put a #literal() around it.
> However, velocity still PARSES the contents of this block, which of course 
> results in parsing exceptions.
> My feeling with "literal" is that it is completely UNINTERPRETED content?
> This SHOULD work:
> #literal()
>  var myId = 'someID';
>  $('#test).append($.template('').apply({myId: myId}));
> #end

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] Commented: (VELOCITY-584) Change the #include directive ignore the SSI version of include

[JIRA]

[ 
https://issues.apache.org/jira/browse/VELOCITY-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12662517#action_12662517
 ] 

Jarkko Viinamäki commented on VELOCITY-584:
---

The new escaping syntax introduced in VELOCITY-661 now helps with this issue.

> Change the #include directive ignore the SSI version of include
> ---
>
> Key: VELOCITY-584
> URL: https://issues.apache.org/jira/browse/VELOCITY-584
> Project: Velocity
>  Issue Type: Improvement
>  Components: Engine
>Affects Versions: 1.5
>Reporter: Tim White
> Fix For: 2.0
>
>
> When processing a file that happens to have the SSI version of 'include' in 
> it, the velocity engine breaks.
> There are many cases where we end up with files that contain both, before 
> they are cleaned up.
> 
> Essentially, if it sees that syntax, it needs to ignore the include.  A 
> suggestion would be to check for any amount of whitespace after the #include, 
> and then "file=".  I don't think that will step on proper Velocity include 
> syntax.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] Created: (VELOCITY-665) issues.Velocity614TestCase fails because patch for VELOCITY-71 was removed

[JIRA]

issues.Velocity614TestCase fails because patch for VELOCITY-71 was removed
--

 Key: VELOCITY-665
 URL: https://issues.apache.org/jira/browse/VELOCITY-665
 Project: Velocity
  Issue Type: Bug
Affects Versions: 1.6.2, 1.7
Reporter: Jarkko Viinamäki
Assignee: Byron Foster


In VelocimacroProxy.checkArgs there is no longer check for the validity of 
macro arguments. As a result, Velocity614TestCase fails. I can't see why we 
could remove the macro argument check?

Otherwise good job on refactoring the init/checkArgs logic. I was thinking 
about the same thing. Now there is no synchronized block overhead.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] Resolved: (VELOCITY-665) issues.Velocity614TestCase fails because patch for VELOCITY-71 was removed

[JIRA]

 [ 
https://issues.apache.org/jira/browse/VELOCITY-665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarkko Viinamäki resolved VELOCITY-665.
---

Resolution: Invalid

Oops for some reason I didn't get all the updates (maybe I had updated the 
wrong directory?). The test passes now and the implementation looks good. My 
mistake. Marking this as invalid.

> issues.Velocity614TestCase fails because patch for VELOCITY-71 was removed
> --
>
> Key: VELOCITY-665
> URL: https://issues.apache.org/jira/browse/VELOCITY-665
> Project: Velocity
>  Issue Type: Bug
>Affects Versions: 1.6.2, 1.7
>Reporter: Jarkko Viinamäki
>Assignee: Byron Foster
>
> In VelocimacroProxy.checkArgs there is no longer check for the validity of 
> macro arguments. As a result, Velocity614TestCase fails. I can't see why we 
> could remove the macro argument check?
> Otherwise good job on refactoring the init/checkArgs logic. I was thinking 
> about the same thing. Now there is no synchronized block overhead.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] Created: (VELOCITY-666) RFC: new directive: #call

[JIRA]

RFC: new directive: #call
-

 Key: VELOCITY-666
 URL: https://issues.apache.org/jira/browse/VELOCITY-666
 Project: Velocity
  Issue Type: Improvement
Affects Versions: 1.6.2, 1.7
Reporter: Jarkko Viinamäki


Inspired by VELOCITY-583 (BlockMacro support) I implemented the same 
functionality in a slightly different way.

This patch introduces a new directive #call("mymacro" $arg1 $arg2 ... ) any 
valid Velocity content here #end

This directive causes a call to defined macro with given arguments AND passes 
the enclosed AST as an argument which can be referenced with $bodyContent 
(default, name is configurable).

An example:

 #set($foobar = "yeah!")
 
 #macro(strong $txt)
 $bodyContent $txt
 #end

 #call("strong" $foobar)
 This text is underlined and bold
 #end
 

Will print:

 This text is underlined and bold yeah!

Like I commented in  VELOCITY-583 the same thing can be done by first using 
#define to build up some custom AST and then pass that AST as an argument to 
some macro. While it works, it's not as convenient as this syntax. This patch 
however increases the amount of code lines in Velocity and the implementation 
is a bit "hackish" so even I'm not totally convinced whether we should commit 
this. 

But anyway, here it is, I'd love to hear your comments.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] Updated: (VELOCITY-666) RFC: new directive: #call

[JIRA]

 [ 
https://issues.apache.org/jira/browse/VELOCITY-666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarkko Viinamäki updated VELOCITY-666:
--

Attachment: velocity-call-directive.patch

Here's the patch. This issue got ID 666. Nomen ist omen? ;)

> RFC: new directive: #call
> -
>
> Key: VELOCITY-666
> URL: https://issues.apache.org/jira/browse/VELOCITY-666
> Project: Velocity
>  Issue Type: Improvement
>Affects Versions: 1.6.2, 1.7
>Reporter: Jarkko Viinamäki
> Attachments: velocity-call-directive.patch
>
>
> Inspired by VELOCITY-583 (BlockMacro support) I implemented the same 
> functionality in a slightly different way.
> This patch introduces a new directive #call("mymacro" $arg1 $arg2 ... ) any 
> valid Velocity content here #end
> This directive causes a call to defined macro with given arguments AND passes 
> the enclosed AST as an argument which can be referenced with $bodyContent 
> (default, name is configurable).
> An example:
>  #set($foobar = "yeah!")
>  
>  #macro(strong $txt)
>  $bodyContent $txt
>  #end
>  #call("strong" $foobar)
>  This text is underlined and bold
>  #end
>  
> Will print:
>  This text is underlined and bold yeah!
> Like I commented in  VELOCITY-583 the same thing can be done by first using 
> #define to build up some custom AST and then pass that AST as an argument to 
> some macro. While it works, it's not as convenient as this syntax. This patch 
> however increases the amount of code lines in Velocity and the implementation 
> is a bit "hackish" so even I'm not totally convinced whether we should commit 
> this. 
> But anyway, here it is, I'd love to hear your comments.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] Updated: (VELOCITY-666) RFC: new directive: #call

[JIRA]

 [ 
https://issues.apache.org/jira/browse/VELOCITY-666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarkko Viinamäki updated VELOCITY-666:
--

Attachment: velocity-blockmacro.patch

Hmm I agree that #call... format is a bit ugly. Jonathan is right though that 
nesting is an important feature that the engine should support.

Here's another attempt to fix this issue (velocity-blockmacro.patch). I renamed 
the feature to BlockMacro. I also removed it from directives.properties so it 
does not clash with anything that already exists.

The new syntax is:

#...@yourmacroname($arg1 $arg2) any valid velocity AST here #end

so basically the syntax is exactly the same as for normal macros except you put 
that @ prefix to the macro name. That tells Velocity that there's a macro AST 
body that should be passed to the actual macro.

And in the macro you can refer to the passed body 0-N times. Like:

#macro(yourMacroName $foo $bar)
   $bodyContent
#end

Anyway, since normal Velocity macros are LINE directives, there must be some 
way to tell Velocity when a body follows the call. I think this is pretty clean 
syntax. 

> RFC: new directive: #call
> -
>
> Key: VELOCITY-666
> URL: https://issues.apache.org/jira/browse/VELOCITY-666
> Project: Velocity
>  Issue Type: Improvement
>Affects Versions: 1.6.2, 1.7
>Reporter: Jarkko Viinamäki
> Attachments: velocity-blockmacro.patch, velocity-call-directive.patch
>
>
> Inspired by VELOCITY-583 (BlockMacro support) I implemented the same 
> functionality in a slightly different way.
> This patch introduces a new directive #call("mymacro" $arg1 $arg2 ... ) any 
> valid Velocity content here #end
> This directive causes a call to defined macro with given arguments AND passes 
> the enclosed AST as an argument which can be referenced with $bodyContent 
> (default, name is configurable).
> An example:
>  #set($foobar = "yeah!")
>  
>  #macro(strong $txt)
>  $bodyContent $txt
>  #end
>  #call("strong" $foobar)
>  This text is underlined and bold
>  #end
>  
> Will print:
>  This text is underlined and bold yeah!
> Like I commented in  VELOCITY-583 the same thing can be done by first using 
> #define to build up some custom AST and then pass that AST as an argument to 
> some macro. While it works, it's not as convenient as this syntax. This patch 
> however increases the amount of code lines in Velocity and the implementation 
> is a bit "hackish" so even I'm not totally convinced whether we should commit 
> this. 
> But anyway, here it is, I'd love to hear your comments.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] Created: (VELOCITY-668) Minor performance tweaks based on Findbugs findings

[JIRA]

Minor performance tweaks based on Findbugs findings
---

 Key: VELOCITY-668
 URL: https://issues.apache.org/jira/browse/VELOCITY-668
 Project: Velocity
  Issue Type: Improvement
Affects Versions: 1.7
Reporter: Jarkko Viinamäki
 Attachments: velocity-minor-perf-tweaks.patch

Mainly change two inner classes to static inner classes and a few other slight 
modifications. See the patch.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] Updated: (VELOCITY-668) Minor performance tweaks based on Findbugs findings

[JIRA]

 [ 
https://issues.apache.org/jira/browse/VELOCITY-668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarkko Viinamäki updated VELOCITY-668:
--

Attachment: velocity-minor-perf-tweaks.patch

> Minor performance tweaks based on Findbugs findings
> ---
>
> Key: VELOCITY-668
> URL: https://issues.apache.org/jira/browse/VELOCITY-668
> Project: Velocity
>  Issue Type: Improvement
>Affects Versions: 1.7
>Reporter: Jarkko Viinamäki
> Attachments: velocity-minor-perf-tweaks.patch
>
>
> Mainly change two inner classes to static inner classes and a few other 
> slight modifications. See the patch.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] Commented: (VELOCITY-668) Minor performance tweaks based on Findbugs findings

[JIRA]

[ 
https://issues.apache.org/jira/browse/VELOCITY-668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12665094#action_12665094
 ] 

Jarkko Viinamäki commented on VELOCITY-668:
---

Thanks. Note that you need to run "ant parser" and commit generated files 
(Parser.java etc) because otherwise changes made to Parser.jjt won't be 
included in the build.

> Minor performance tweaks based on Findbugs findings
> ---
>
> Key: VELOCITY-668
>     URL: https://issues.apache.org/jira/browse/VELOCITY-668
> Project: Velocity
>  Issue Type: Improvement
>Affects Versions: 1.7
>Reporter: Jarkko Viinamäki
> Attachments: velocity-minor-perf-tweaks.patch
>
>
> Mainly change two inner classes to static inner classes and a few other 
> slight modifications. See the patch.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] Created: (VELOCITY-669) Concurrency bug introduced in 1.7-dev

[JIRA]

Concurrency bug introduced in 1.7-dev
-

 Key: VELOCITY-669
 URL: https://issues.apache.org/jira/browse/VELOCITY-669
 Project: Velocity
  Issue Type: Bug
Affects Versions: 1.7
Reporter: Jarkko Viinamäki
Priority: Blocker


Warning: current SVN head is broken - it fails under heavy load. I don't have 
time to investigate right now but 1.6.1 release version does not have this bug 
(1.6.2 release candidate may have it! - I'm not sure what's included there). 
However, current SVN head fails consistently with my load testing suite when I 
run it under JRat profiling:

---
Test set: org.apache.velocity.test.load.Velocity24LoadTest
---
Tests run: 250, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 71.032 sec 
<<< FAILURE!
testRendering(org.apache.velocity.test.load.Velocity24Test)  Time elapsed: 
0.125 sec  <<< ERROR!
java.lang.NullPointerException
at java.io.Writer.write(Writer.java:110)
at 
org.apache.velocity.runtime.parser.node.ASTText.render_$jrat(ASTText.java:83)
at org.apache.velocity.runtime.parser.node.ASTText.render(ASTText.java)
at 
org.apache.velocity.runtime.parser.node.ASTBlock.render_$jrat(ASTBlock.java:72)
at 
org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java)
at 
org.apache.velocity.runtime.directive.VelocimacroProxy.render_$jrat(VelocimacroProxy.java:222)
at 
org.apache.velocity.runtime.directive.VelocimacroProxy.render(VelocimacroProxy.java)
at 
org.apache.velocity.runtime.directive.RuntimeMacro.render_$jrat(RuntimeMacro.java:295)
at 
org.apache.velocity.runtime.directive.RuntimeMacro.render(RuntimeMacro.java)
at 
org.apache.velocity.runtime.directive.RuntimeMacro.render_$jrat(RuntimeMacro.java:215)
at 
org.apache.velocity.runtime.directive.RuntimeMacro.render(RuntimeMacro.java)
at 
org.apache.velocity.runtime.parser.node.ASTDirective.render_$jrat(ASTDirective.java:198)
at 
org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java)
at 
org.apache.velocity.runtime.parser.node.SimpleNode.render_$jrat(SimpleNode.java:342)
at 
org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java)
at org.apache.velocity.Template.merge_$jrat(Template.java:340)
at org.apache.velocity.Template.merge(Template.java)
at org.apache.velocity.Template.merge_$jrat(Template.java:248)
at org.apache.velocity.Template.merge(Template.java)
at 
org.apache.velocity.test.load.Velocity24Test.testRendering_$jrat(Velocity24Test.java:52)
at 
org.apache.velocity.test.load.Velocity24Test.testRendering(Velocity24Test.java)

Although I'm not sure, I strongly suspect that this has got something to do 
with refactoring done (2009-01-11) for VelocimacroProxy.init. In 1.6.1 the init 
function initializes the nodeTree variable but if I'm not mistaken, in current 
SVN head this does not happen(!). It seems that under certain conditions the 
engine tries to render an ASTText node that has not been initialized (char 
array is null) which causes this exception. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] Commented: (VELOCITY-669) Concurrency bug introduced in 1.7-dev

[JIRA]

[ 
https://issues.apache.org/jira/browse/VELOCITY-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12665486#action_12665486
 ] 

Jarkko Viinamäki commented on VELOCITY-669:
---

Uhoh. Based on a quick peek I feel very uneasy about the changes you made. I'm 
afraid that they might change the engine behaviour/introduce new subtle bugs 
although tests seem to pass.

For instance in Parser.jjt you added that macroNames HashMap. Now 
escapedDirective method does not ask RuntimeServices anymore if some string is 
a macro or not. Instead it takes a look at macroNames. I think this is not the 
same thing since it is not guaranteed that the Parser instance knows about all 
macros.

You also removed Macro.processAndRegister and changed so that macro is 
registered late at init and it feels a bit out of place. This may have some 
side effects (unnecessary reparsing of macros etc)? Is it certain that the Node 
argument passed to init is the same argument passed to processAndRegister (the 
macro body?). 

--

I tested that by simply adding "nodeTree.init(null, rsvc);" to the last line of 
VelocimacroManager.MacroEntry constructor fixes this bug. Context can be null 
for init calls since init isn't (and should not be) context dependent. The only 
AST element that refers Context is ASTStringLiteral which can be changed to 
call super.getTemplateName() instead of getting it from the Context.

> Concurrency bug introduced in 1.7-dev
> -
>
> Key: VELOCITY-669
> URL: https://issues.apache.org/jira/browse/VELOCITY-669
> Project: Velocity
>  Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Jarkko Viinamäki
>Priority: Blocker
>
> Warning: current SVN head is broken - it fails under heavy load. I don't have 
> time to investigate right now but 1.6.1 release version does not have this 
> bug (1.6.2 release candidate may have it! - I'm not sure what's included 
> there). However, current SVN head fails consistently with my load testing 
> suite when I run it under JRat profiling:
> ---
> Test set: org.apache.velocity.test.load.Velocity24LoadTest
> ---
> Tests run: 250, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 71.032 sec 
> <<< FAILURE!
> testRendering(org.apache.velocity.test.load.Velocity24Test)  Time elapsed: 
> 0.125 sec  <<< ERROR!
> java.lang.NullPointerException
>   at java.io.Writer.write(Writer.java:110)
>   at 
> org.apache.velocity.runtime.parser.node.ASTText.render_$jrat(ASTText.java:83)
>   at org.apache.velocity.runtime.parser.node.ASTText.render(ASTText.java)
>   at 
> org.apache.velocity.runtime.parser.node.ASTBlock.render_$jrat(ASTBlock.java:72)
>   at 
> org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java)
>   at 
> org.apache.velocity.runtime.directive.VelocimacroProxy.render_$jrat(VelocimacroProxy.java:222)
>   at 
> org.apache.velocity.runtime.directive.VelocimacroProxy.render(VelocimacroProxy.java)
>   at 
> org.apache.velocity.runtime.directive.RuntimeMacro.render_$jrat(RuntimeMacro.java:295)
>   at 
> org.apache.velocity.runtime.directive.RuntimeMacro.render(RuntimeMacro.java)
>   at 
> org.apache.velocity.runtime.directive.RuntimeMacro.render_$jrat(RuntimeMacro.java:215)
>   at 
> org.apache.velocity.runtime.directive.RuntimeMacro.render(RuntimeMacro.java)
>   at 
> org.apache.velocity.runtime.parser.node.ASTDirective.render_$jrat(ASTDirective.java:198)
>   at 
> org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java)
>   at 
> org.apache.velocity.runtime.parser.node.SimpleNode.render_$jrat(SimpleNode.java:342)
>   at 
> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java)
>   at org.apache.velocity.Template.merge_$jrat(Template.java:340)
>   at org.apache.velocity.Template.merge(Template.java)
>   at org.apache.velocity.Template.merge_$jrat(Template.java:248)
>   at org.apache.velocity.Template.merge(Template.java)
>   at 
> org.apache.velocity.test.load.Velocity24Test.testRendering_$jrat(Velocity24Test.java:52)
>   at 
> org.apache.velocity.test.load.Velocity24Test.testRendering(Velocity24Test.java)
> Although I'm not sure, I strongly suspect that this has got something to do 
> with refactoring done (2009-01-11) for VelocimacroProxy.init. In 1.6.1 the 
> init function initializes the nodeTree variable but if I'm not mistaken, in 
> current SVN hea

[jira] Commented: (VELOCITY-671) Undefined macro in block form causes NPE

[JIRA]

[ 
https://issues.apache.org/jira/browse/VELOCITY-671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12665487#action_12665487
 ] 

Jarkko Viinamäki commented on VELOCITY-671:
---

Can you create a TestCase for that?

This one seems to pass without an Exception:

public void testUndefinedMacroWithEmptyBody() throws Exception
{
String template = "#...@foo()#end";
String result = "#...@foo()#end";

assertEvalEquals(result, template);
}


> Undefined macro in block form causes NPE
> 
>
> Key: VELOCITY-671
> URL: https://issues.apache.org/jira/browse/VELOCITY-671
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
>Affects Versions: 1.7
>Reporter: Byron Foster
>
> And undefined macro such as:
> #...@foo()#end
> Causes an NPE

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] Commented: (VELOCITY-672) add '#for' as a synonym for '#foreach'

[JIRA]

[ 
https://issues.apache.org/jira/browse/VELOCITY-672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12665508#action_12665508
 ] 

Jarkko Viinamäki commented on VELOCITY-672:
---

I'd prefer to keep the amount of directives to minimum. I can't see any real 
benefits of this alias. It just creates a need for additional documentation, 
tests and requires new lines of code in the parser. Foreach is consistent with 
several other scripting languages.

> add '#for' as a synonym for '#foreach'
> --
>
> Key: VELOCITY-672
>     URL: https://issues.apache.org/jira/browse/VELOCITY-672
> Project: Velocity
>  Issue Type: Improvement
>  Components: Engine
>Reporter: Byron Foster
>Priority: Minor
> Fix For: 1.7
>
>
> Add 'for' as a synonym for 'foreach'  such as:
> #for ($order in $orders)
>   $order.price
> #end

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] Updated: (VELOCITY-671) Undefined macro in block form causes NPE

[JIRA]

 [ 
https://issues.apache.org/jira/browse/VELOCITY-671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarkko Viinamäki updated VELOCITY-671:
--

Attachment: velocity-671.patch

This should fix it. I forgot to initialize the Runtime macro instance properly 
in BlockMacro init. As a result, getTemplateName() returned null and 
ConcurrentHashMap didn't like that.

See the patch.

> Undefined macro in block form causes NPE
> 
>
> Key: VELOCITY-671
> URL: https://issues.apache.org/jira/browse/VELOCITY-671
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
>Affects Versions: 1.7
>Reporter: Byron Foster
> Attachments: velocity-671.patch
>
>
> And undefined macro such as:
> #...@foo()#end
> Causes an NPE

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] Issue Comment Edited: (VELOCITY-672) add '#for' as a synonym for '#foreach'

[JIRA]

[ 
https://issues.apache.org/jira/browse/VELOCITY-672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12665810#action_12665810
 ] 

wyla edited comment on VELOCITY-672 at 1/21/09 4:08 AM:


In addition, almost in all programming languages the syntax of "for" is:

for (expr1; expr2; expr3)
statement

and if that did not work, it would surprise the user. 

-1 for this. Sorry.

  was (Author: wyla):
In addition, almost in all programming languages the syntax of "for" is:

for (expr1; expr2; expr3)
statement

and if that would not work, it would surprise the user. 

-1 for this. Sorry.
  
> add '#for' as a synonym for '#foreach'
> --
>
> Key: VELOCITY-672
> URL: https://issues.apache.org/jira/browse/VELOCITY-672
> Project: Velocity
>  Issue Type: Improvement
>  Components: Engine
>Reporter: Byron Foster
>Priority: Minor
> Fix For: 1.7
>
>
> Add 'for' as a synonym for 'foreach'  such as:
> #for ($order in $orders)
>   $order.price
> #end

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] Commented: (VELOCITY-672) add '#for' as a synonym for '#foreach'

[JIRA]

[ 
https://issues.apache.org/jira/browse/VELOCITY-672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12665810#action_12665810
 ] 

Jarkko Viinamäki commented on VELOCITY-672:
---

In addition, almost in all programming languages the syntax of "for" is:

for (expr1; expr2; expr3)
statement

and if that would not work, it would surprise the user. 

-1 for this. Sorry.

> add '#for' as a synonym for '#foreach'
> --
>
> Key: VELOCITY-672
>     URL: https://issues.apache.org/jira/browse/VELOCITY-672
> Project: Velocity
>  Issue Type: Improvement
>  Components: Engine
>Reporter: Byron Foster
>Priority: Minor
> Fix For: 1.7
>
>
> Add 'for' as a synonym for 'foreach'  such as:
> #for ($order in $orders)
>   $order.price
> #end

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] Commented: (VELOCITY-670) Macro escaping inconsistent with forward references

[JIRA]

[ 
https://issues.apache.org/jira/browse/VELOCITY-670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12665835#action_12665835
 ] 

Jarkko Viinamäki commented on VELOCITY-670:
---

Let's remember that in upcoming Velocity 1.7 you can now use #[[ anything ]]# 
to escape things. 

> Macro escaping inconsistent with forward references
> ---
>
> Key: VELOCITY-670
> URL: https://issues.apache.org/jira/browse/VELOCITY-670
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
>Affects Versions: 1.6
>Reporter: Byron Foster
>Priority: Minor
>
> Escaping a macro behaves differently if the macro is forward referenced. for 
> example the following:
> #macro(foo)bar#end
> \#foo
> gives result:
> #foo
> However this:
> \#foo
> #macro(foo)bar#end
> gives result:
> \#foo

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] Created: (VELOCITY-674) Lots of unused imports in source code files

[JIRA]

Lots of unused imports in source code files
---

 Key: VELOCITY-674
 URL: https://issues.apache.org/jira/browse/VELOCITY-674
 Project: Velocity
  Issue Type: Improvement
Affects Versions: 1.6.2, 1.7
Reporter: Jarkko Viinamäki
Priority: Trivial


I noticed in Eclipse that several Velocity files have lots of unused imports. 
These could be cleaned with "Organize imports" feature for example. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] Updated: (VELOCITY-675) #@foo causes an NPE

[JIRA]

 [ 
https://issues.apache.org/jira/browse/VELOCITY-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarkko Viinamäki updated VELOCITY-675:
--

Attachment: velocity-675.patch

This should fix it. ASTDirective now checks if the node has a body. If it 
doesn't, it does not create a BlockMacro instance and renders as literal 
instead.

> #...@foo causes an NPE
> ---
>
> Key: VELOCITY-675
> URL: https://issues.apache.org/jira/browse/VELOCITY-675
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
>Affects Versions: 1.7
>Reporter: Byron Foster
> Attachments: velocity-675.patch
>
>
> The following syntax (without #end) causes an NPE:  "#...@foo"
> class java.lang.NullPointerException
> apache.velocity.runtime.parser.node.SimpleNode.jjtGetChild(SimpleNode.java:183)
>  
> org.apache.velocity.runtime.directive.BlockMacro.init(BlockMacro.java:107) 
> org.apache.velocity.runtime.parser.node.ASTDirective.init(ASTDirective.java:138)
>  
> org.apache.velocity.runtime.parser.node.SimpleNode.init(SimpleNode.java:309) 
> org.apache.velocity.Template.initDocument(Template.java:218) 
> org.apache.velocity.Template.process(Template.java:126) 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] Updated: (VELOCITY-676) #[[##x]]# causes StringIndexOutOfBoundsException

[JIRA]

 [ 
https://issues.apache.org/jira/browse/VELOCITY-676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarkko Viinamäki updated VELOCITY-676:
--

Attachment: velocity-676.patch

This should fix it. 

I changed the parser so that SINGLE_LINE_COMMENT_START is not detected in all 
states. The problem was the while IN_TEXTBLOCK state the parser ran into ## and 
processed SINGLE_LINE_COMMENT_START block which in turn somehow erased the 
input buffer.

I hope this parser comment processing change doesn't break anything. Tests pass 
at least.



> #[[##x]]# causes StringIndexOutOfBoundsException
> 
>
> Key: VELOCITY-676
> URL: https://issues.apache.org/jira/browse/VELOCITY-676
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
>Affects Versions: 1.7
>Reporter: Byron Foster
> Attachments: velocity-676.patch
>
>
> The following VTL:
> #[[##x]]#
> Causes:
> Threw: class java.lang.StringIndexOutOfBoundsException
> Msg: String index out of range: -2
> java.lang.String.substring(String.java:1768) 
> org.apache.velocity.runtime.parser.node.ASTTextblock.init(ASTTextblock.java:79)
>  
> org.apache.velocity.runtime.parser.node.SimpleNode.init(SimpleNode.java:309) 
> org.apache.velocity.Template.initDocument(Template.java:218) 
> org.apache.velocity.Template.process(Template.java:126) 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] Commented: (VELOCITY-677) a '#' or '$' character at the end of VTL causes a ParseException

[JIRA]

[ 
https://issues.apache.org/jira/browse/VELOCITY-677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12666173#action_12666173
 ] 

Jarkko Viinamäki commented on VELOCITY-677:
---

Since there's a trivial workaround for this (use a reference to put that # or $ 
in place), I'm not sure if this is worth fixing _IF_ it requires complex 
tweaking of the parser. It's already cryptic enough. :)

> a '#' or '$' character at the end of VTL causes a ParseException
> 
>
> Key: VELOCITY-677
> URL: https://issues.apache.org/jira/browse/VELOCITY-677
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
>Affects Versions: 1.6, 1.6.1, 1.7
>Reporter: Byron Foster
>Priority: Minor
>
> If either the character '#' or '$' is the last character in VTL, then the 
> following results:
> Threw: class org.apache.velocity.exception.ParseErrorException
> Msg: Lexical error: org.apache.velocity.runtime.parser.TokenMgrError: Lexical 
> error at line 4, column 2. Encountered: after : ""
> org.apache.velocity.Template.process(Template.java:142) 
> org.apache.velocity.runtime.resource.ResourceManagerImpl.refreshResource(ResourceManagerImpl.java:556)
>  
> org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:319)
>  
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1442)
>  
> org.apache.velocity.runtime.RuntimeSingleton.getTemplate(RuntimeSingleton.java:319)
>  
> org.apache.velocity.app.Velocity.mergeTemplate(Velocity.java:332) 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] Created: (VELOCITY-680) RFC: New #local directive that behaves like #set but puts things into local context in macro rendering

[JIRA]

RFC: New #local directive that behaves like #set but puts things into local 
context in macro rendering
--

 Key: VELOCITY-680
 URL: https://issues.apache.org/jira/browse/VELOCITY-680
 Project: Velocity
  Issue Type: New Feature
Affects Versions: 1.7
Reporter: Jarkko Viinamäki
 Attachments: velocity-local-directive.patch

It would be very useful to be able to set variables that are in local macro 
scope. That is, they do not overwrite "global" variables and are thrown away 
after macro rendering. This would allow people to build macro libraries that do 
not clash so easily with each other.

There is some implementation of a "LocalDirective" in 
experimental/localdirective but I didn't quite get it and it doesn't follow the 
same syntax as #set. I used a few minutes to hack together this alternative 
implementation which behaves exactly like #set but it puts things in local 
context only.

There's only one test case since this is Request-for-Comments type of patch.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] Updated: (VELOCITY-680) RFC: New #local directive that behaves like #set but puts things into local context in macro rendering

[JIRA]

 [ 
https://issues.apache.org/jira/browse/VELOCITY-680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarkko Viinamäki updated VELOCITY-680:
--

Attachment: velocity-local-directive.patch

> RFC: New #local directive that behaves like #set but puts things into local 
> context in macro rendering
> --
>
> Key: VELOCITY-680
> URL: https://issues.apache.org/jira/browse/VELOCITY-680
> Project: Velocity
>  Issue Type: New Feature
>Affects Versions: 1.7
>Reporter: Jarkko Viinamäki
> Attachments: velocity-local-directive.patch
>
>
> It would be very useful to be able to set variables that are in local macro 
> scope. That is, they do not overwrite "global" variables and are thrown away 
> after macro rendering. This would allow people to build macro libraries that 
> do not clash so easily with each other.
> There is some implementation of a "LocalDirective" in 
> experimental/localdirective but I didn't quite get it and it doesn't follow 
> the same syntax as #set. I used a few minutes to hack together this 
> alternative implementation which behaves exactly like #set but it puts things 
> in local context only.
> There's only one test case since this is Request-for-Comments type of patch.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] Commented: (VELOCITY-680) RFC: New #local directive that behaves like #set but puts things into local context in macro rendering

[JIRA]

[ 
https://issues.apache.org/jira/browse/VELOCITY-680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12666249#action_12666249
 ] 

Jarkko Viinamäki commented on VELOCITY-680:
---

I specifically wanted to avoid using that syntax since I consider that quite 
error prone and a bit hard to keep track of. Also you can't set any global 
variables when you are inside that local block.

> RFC: New #local directive that behaves like #set but puts things into local 
> context in macro rendering
> --
>
> Key: VELOCITY-680
> URL: https://issues.apache.org/jira/browse/VELOCITY-680
> Project: Velocity
>  Issue Type: New Feature
>Affects Versions: 1.7
>Reporter: Jarkko Viinamäki
> Attachments: velocity-local-directive.patch
>
>
> It would be very useful to be able to set variables that are in local macro 
> scope. That is, they do not overwrite "global" variables and are thrown away 
> after macro rendering. This would allow people to build macro libraries that 
> do not clash so easily with each other.
> There is some implementation of a "LocalDirective" in 
> experimental/localdirective but I didn't quite get it and it doesn't follow 
> the same syntax as #set. I used a few minutes to hack together this 
> alternative implementation which behaves exactly like #set but it puts things 
> in local context only.
> There's only one test case since this is Request-for-Comments type of patch.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] Commented: (VELOCITY-681) [regression] Changes on the macro parameters are not persisted outside the macro call

[JIRA]

[ 
https://issues.apache.org/jira/browse/VELOCITY-681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12666441#action_12666441
 ] 

Jarkko Viinamäki commented on VELOCITY-681:
---

I tested this and Sergiu's test case passes with 1.5 and 1.6 but not with 
1.6.1. Nathan has valid points though. Maybe we could introduce (yet another) 
configuration file option for this so that both 1.6.1 type functionality and 
the old one would be possible?

I didn't understand why there were these special .literal.$varName checks in 
ProxyVMContext in Sergiu's patch. There should be no need to check for those 
since there are needed only for "render literal if null" functionality and the 
only classes that should know about that special key structure are 
VelocimacroProxy and ASTReference.

> [regression] Changes on the macro parameters are not persisted outside the 
> macro call
> -
>
> Key: VELOCITY-681
> URL: https://issues.apache.org/jira/browse/VELOCITY-681
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
>Affects Versions: 1.6.1
>Reporter: Sergiu Dumitriu
>Priority: Critical
> Fix For: 1.6.2, 1.7
>
> Attachments: VELOCITY-681-1.6.patch, VELOCITY-681-trunk.patch
>
>
> The fix for VELOCITY-615 was too radical, since it completely disables 
> #setting new values to the formal arguments. A minimalistic example that used 
> to work up to 1.6 (but not with 1.6.1) is:
> {noformat}
> #macro(myMacro $result)
>   #set($result = 'some value')
> #end
> #myMacro($x)
> $x
> {/noformat}
> which prints $x (as an undefined variable).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] Commented: (VELOCITY-681) [regression] Changes on the macro parameters are not persisted outside the macro call

[JIRA]

[ 
https://issues.apache.org/jira/browse/VELOCITY-681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12666572#action_12666572
 ] 

Jarkko Viinamäki commented on VELOCITY-681:
---

Please don't commit this yet. 

I need to review this carefully since there is some funny stuff happing with 
.literal.$varName that should not be at all in ProxyVMContext. It's possible 
that purpose of those keys have been misunderstood.

> [regression] Changes on the macro parameters are not persisted outside the 
> macro call
> -
>
> Key: VELOCITY-681
> URL: https://issues.apache.org/jira/browse/VELOCITY-681
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
>Affects Versions: 1.6.1
>Reporter: Sergiu Dumitriu
>Priority: Critical
> Fix For: 1.6.2, 1.7
>
> Attachments: VELOCITY-681-1.6.patch, VELOCITY-681-trunk.patch
>
>
> The fix for VELOCITY-615 was too radical, since it completely disables 
> #setting new values to the formal arguments. A minimalistic example that used 
> to work up to 1.6 (but not with 1.6.1) is:
> {noformat}
> #macro(myMacro $result)
>   #set($result = 'some value')
> #end
> #myMacro($x)
> $x
> {/noformat}
> which prints $x (as an undefined variable).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] Updated: (VELOCITY-685) BlockMacros fail with strict number of macro arguments

[JIRA]

 [ 
https://issues.apache.org/jira/browse/VELOCITY-685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarkko Viinamäki updated VELOCITY-685:
--

Attachment: velocity-685.patch

Thanks for finding these bugs so quickly Byron! Good testing!

Here's a patch that should fix the issue.

> BlockMacros fail with strict number of macro arguments
> --
>
> Key: VELOCITY-685
> URL: https://issues.apache.org/jira/browse/VELOCITY-685
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
>Reporter: Byron Foster
> Fix For: 1.7
>
> Attachments: velocity-685.patch
>
>
> With 'velocimacro.arguments.strict = true' the following VTL:
> #macro(foo)#end
> #...@foo() junk #end
> Results in:
> Threw: class org.apache.velocity.exception.ParseErrorException
> Msg: VM #foo: too many arguments to macro. Wanted 0 got 1 at /foo.vm[line 2, 
> column 1]
> org.apache.velocity.runtime.directive.RuntimeMacro.render(RuntimeMacro.java:283)
>  
> org.apache.velocity.runtime.directive.BlockMacro.render(BlockMacro.java:126) 
> org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:207)
>  
> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:342)
>  
> org.apache.velocity.Template.merge(Template.java:340) 
> org.apache.velocity.Template.merge(Template.java:248) 
> org.apache.velocity.app.Velocity.mergeTemplate(Velocity.java:343) 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] Commented: (VELOCITY-684) Passing a map literal to a macro call forbids altering the map in any way, while maps bound to an actual parameter may be changed

[JIRA]

[ 
https://issues.apache.org/jira/browse/VELOCITY-684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12666581#action_12666581
 ] 

Jarkko Viinamäki commented on VELOCITY-684:
---

Ahhum... What's the real life use case for this?

> Passing a map literal to a macro call forbids altering the map in any way, 
> while maps bound to an actual parameter may be changed
> -
>
> Key: VELOCITY-684
> URL: https://issues.apache.org/jira/browse/VELOCITY-684
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
>Affects Versions: 1.6.1
>Reporter: Sergiu Dumitriu
>
> For example, with the following macro:
> #macro(changeMap $map)
>   Before: $map.someKey
>   #set($map.someKey = 'new value')
>   After: $map.someKey
> #end
> This call works as expected:
> #set($actualMap = {'someKey' : 'old value'})
> #changeMap($actualMap) => old value, then new value
> But this one doesn't:
> #changeMap({'someKey' : 'old value'}) => old value, then again old value

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] Commented: (VELOCITY-682) #evaluate breaks macro processing

[JIRA]

[ 
https://issues.apache.org/jira/browse/VELOCITY-682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12666591#action_12666591
 ] 

Jarkko Viinamäki commented on VELOCITY-682:
---

Hmm. This works for me. What kind of JUnit TestCase did you use Byron?



> #evaluate breaks macro processing
> -
>
> Key: VELOCITY-682
> URL: https://issues.apache.org/jira/browse/VELOCITY-682
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
>Affects Versions: 1.6.1
>Reporter: Sergiu Dumitriu
>
> When using #evaluate, all further macro processing is broken; old macros are 
> not recognized anymore, and new macros cannot be defined.
> For example:
> {noformat}
> #macro(aSimpleMacro)
>   This is a simple macro
> #end
> ## called 3 times to show that it works each time
> #aSimpleMacro()
> #aSimpleMacro()
> #aSimpleMacro()
> #macro(doEval $b)
>   #evaluate($x)
> #end
> #set($x = 'value of x')
> #doEval('$x')
> ## after the first call, which used an #evaluate, these two won't work 
> anymore:
> #doEval('$x')
> #doEval('$x')
> #macro(anotherSimpleMacro)
>   This is another simple macro
> #end
> ## This newly defined macro doesn't work, either...
> #anotherSimpleMacro()
> ## And the first macro, which worked well before, suddenly stops working
> #aSimpleMacro()
> {/noformat}
> should print:
> {noformat}
>   This is a simple macro
>   This is a simple macro
>   This is a simple macro
>   value of x
>   value of x
>   value of x
>   This is another simple macro
>   This is a simple macro
> {/noformat}
> but instead prints:
> {noformat}
>   This is a simple macro
>   This is a simple macro
>   This is a simple macro
>   value of x
> #doEval('$x')
> #doEval('$x')
> #anotherSimpleMacro()
> #aSimpleMacro()
> {/noformat}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] Updated: (VELOCITY-680) RFC: New #local directive that behaves like #set but puts things into local context in macro rendering

[JIRA]

 [ 
https://issues.apache.org/jira/browse/VELOCITY-680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarkko Viinamäki updated VELOCITY-680:
--

Attachment: velocity-local-directive-1.1.patch

Here's a bit revised version of the same thing. I kept the try-catch block 
since a) it's simple to implement, b) it doesn't have much performance penalty 
and c) I would like to avoid referring to context in init() because basically 
nodes should not be dependent on context during init.

I also throw the exception in all cases if #local is used outside macro. Some 
strict setting seemed too artificial and it's good to alert the user that he is 
not using the directive properly.

I think that if we have this #local directive, velocimacro.context.localscope 
becomes more or less useless.

I also think that #set is already equivalent to #global.

Nathan's idea about using #local to set variables only in "parsed" context is 
interesting but quite difficult to implement.

Feel free to figure out test cases that break this implementation. Byron is at 
least very good at it. :)

> RFC: New #local directive that behaves like #set but puts things into local 
> context in macro rendering
> --
>
> Key: VELOCITY-680
> URL: https://issues.apache.org/jira/browse/VELOCITY-680
> Project: Velocity
>  Issue Type: New Feature
>Affects Versions: 1.7
>Reporter: Jarkko Viinamäki
> Attachments: velocity-local-directive-1.1.patch, 
> velocity-local-directive.patch
>
>
> It would be very useful to be able to set variables that are in local macro 
> scope. That is, they do not overwrite "global" variables and are thrown away 
> after macro rendering. This would allow people to build macro libraries that 
> do not clash so easily with each other.
> There is some implementation of a "LocalDirective" in 
> experimental/localdirective but I didn't quite get it and it doesn't follow 
> the same syntax as #set. I used a few minutes to hack together this 
> alternative implementation which behaves exactly like #set but it puts things 
> in local context only.
> There's only one test case since this is Request-for-Comments type of patch.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] Commented: (VELOCITY-686) BlockMacro renders $bodyContent on #set

[JIRA]

[ 
https://issues.apache.org/jira/browse/VELOCITY-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12666950#action_12666950
 ] 

Jarkko Viinamäki commented on VELOCITY-686:
---

This is not actually a bug. It's a design decision. $bodyContent is not a 
normal reference because it can contain any complex set of AST nodes and logic. 
It just marks where the passed body should be rendered. Therefore you can't use 
it like a normal reference.



> BlockMacro renders $bodyContent on #set
> ---
>
> Key: VELOCITY-686
> URL: https://issues.apache.org/jira/browse/VELOCITY-686
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
>Reporter: Byron Foster
> Fix For: 1.7
>
>
> Given the following VTL:
> #macro(foo)#set($x = $bodyContent)#end
> #...@foo()bar#end
> renders to:
> bar
> I wonder about calling render on JJTBLOCK types in the ProxyVMContext get 
> method.  Do you think it would be better in ASTReference render?
> There is an interesting use case for BlockMacros which looks something like 
> this:
> #macro(escXML)$tool.escXml($bodyContent)#end
> The above definition could be used to create a filter like the following:
> #...@escxml
>   ## ... rendered stuff to be escaped
> #end
> $tool.escXml can intercept the writer and create a filter.  But as it stands 
> referencing $bodyContent renders the content making this use case impractical.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org