[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???
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
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
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)
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
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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
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
[ 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
[ 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
[ 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
[ 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
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
[ 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
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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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)
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)
[ 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
[ 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
[ 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)
[ 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)
[ 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
[ 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
$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
[ 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
[ 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
[ 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
[ 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
[ 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)
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
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
[ 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
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
[ 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
[ 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
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
[ 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
[ 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
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
[ 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
[ 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'
[ 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
[ 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'
[ 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'
[ 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
[ 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
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
[ 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
[ 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
[ 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
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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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