[jira] Created: (VELOCITY-735) Provide JSR 223 implementation
Provide JSR 223 implementation -- Key: VELOCITY-735 URL: https://issues.apache.org/jira/browse/VELOCITY-735 Project: Velocity Issue Type: New Feature Components: Engine Affects Versions: 1.6.2 Reporter: Thomas Mortagne Would be great that Velocity comes with a JSR 223 implementation like groovy do 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] [Created] (VELTOOLS-140) No proper pom.xml file on maven central for velocity-tools 1.4
No proper pom.xml file on maven central for velocity-tools 1.4 -- Key: VELTOOLS-140 URL: https://issues.apache.org/jira/browse/VELTOOLS-140 Project: Velocity Tools Issue Type: Bug Reporter: Thomas Mortagne See http://repo1.maven.org/maven2/velocity-tools/velocity-tools/1.4/ for example. It's very annoying having maven checking an all repository for a pom.xml file it will never find each time I build. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Created] (VELOCITY-892) Method arguments conversions should be based on Type instead of Class
Thomas Mortagne created VELOCITY-892: Summary: Method arguments conversions should be based on Type instead of Class Key: VELOCITY-892 URL: https://issues.apache.org/jira/browse/VELOCITY-892 Project: Velocity Issue Type: Improvement Components: Engine Affects Versions: 2.0 Reporter: Thomas Mortagne Fix For: 2.0 I was happy to see that method arguments conversion has been added to 2.0 so that I can remove the uberspector we have on XWiki side but unfortunately ConversionHandler is limited to classes which is way too restrictive for us (for example if the parameter type is List it won't do the same thing than if the type is List). Our uberspector can be found on https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodArgumentsUberspector.java to see what we do exactly. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Created] (VELOCITY-894) Maven central JARs don't contains debug information
Thomas Mortagne created VELOCITY-894: Summary: Maven central JARs don't contains debug information Key: VELOCITY-894 URL: https://issues.apache.org/jira/browse/VELOCITY-894 Project: Velocity Issue Type: Bug Components: Build Affects Versions: 2.0 Reporter: Thomas Mortagne As far as I can see the JAR published on velocity-engine-core-2.0.java published on Maven central has been built without the debug information. Makes is quite a pain to understand when happen exactly when you have something to debug. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-894) Maven central JARs don't contains debug information
[ https://issues.apache.org/jira/browse/VELOCITY-894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mortagne updated VELOCITY-894: - Description: As far as I can see the JAR published on velocity-engine-core-2.0.java published on Maven central has been built without the debug information. Makes is quite a pain to understand what happen exactly when you have something to debug. (was: As far as I can see the JAR published on velocity-engine-core-2.0.java published on Maven central has been built without the debug information. Makes is quite a pain to understand when happen exactly when you have something to debug.) > Maven central JARs don't contains debug information > --- > > Key: VELOCITY-894 > URL: https://issues.apache.org/jira/browse/VELOCITY-894 > Project: Velocity > Issue Type: Bug > Components: Build >Affects Versions: 2.0 >Reporter: Thomas Mortagne >Priority: Major > > As far as I can see the JAR published on velocity-engine-core-2.0.java > published on Maven central has been built without the debug information. > Makes is quite a pain to understand what happen exactly when you have > something to debug. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-894) Maven central JARs don't contains debug information
[ https://issues.apache.org/jira/browse/VELOCITY-894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16499131#comment-16499131 ] Thomas Mortagne commented on VELOCITY-894: -- "vital" is a bit strong as well as "pure nonsense" :) It's indeed the first time I encounter a JAR dependency without the debug symbol (and XWiki have quite a few dependencies :)) so I was very surprised. I think the logic is more the opposite, I really doubt this optimization bring much value in practice and having the debug symbol make debugging a lot easier. bq. someone willing to have debug information can still build binaries with it Yes I could checkout the tag, modify the pom and hope that all will build fine with my version of Maven and that I will get the exact same thing but with debug symbol but I would really prefer not to ;) > Maven central JARs don't contains debug information > --- > > Key: VELOCITY-894 > URL: https://issues.apache.org/jira/browse/VELOCITY-894 > Project: Velocity > Issue Type: Bug > Components: Build >Affects Versions: 2.0 >Reporter: Thomas Mortagne >Priority: Major > > As far as I can see the JAR published on velocity-engine-core-2.0.java > published on Maven central has been built without the debug information. > Makes is quite a pain to understand what happen exactly when you have > something to debug. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Created] (VELOCITY-896) Regression in the handling of string containing a sharp
Thomas Mortagne created VELOCITY-896: Summary: Regression in the handling of string containing a sharp Key: VELOCITY-896 URL: https://issues.apache.org/jira/browse/VELOCITY-896 Project: Velocity Issue Type: Bug Affects Versions: 2.0 Reporter: Thomas Mortagne The following produce a ParseErrorException after upgrading to Velocity 2: {code} #set($var = "#") {code} {noformat} org.xwiki.velocity.XWikiVelocityException: Failed to evaluate content with id [mytemplate] at org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:279) at org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:244) at org.xwiki.velocity.internal.DefaultVelocityEngineTest.assertEvaluate(DefaultVelocityEngineTest.java:92) at org.xwiki.velocity.internal.DefaultVelocityEngineTest.assertEvaluate(DefaultVelocityEngineTest.java:85) at org.xwiki.velocity.internal.DefaultVelocityEngineTest.testMisc(DefaultVelocityEngineTest.java:287) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:436) at org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:115) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$6(TestMethodTestDescriptor.java:170) at org.junit.jupiter.engine.execution.ThrowableCollector.execute(ThrowableCollector.java:40) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:166) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:113) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:58) at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$3(HierarchicalTestExecutor.java:112) at org.junit.platform.engine.support.hierarchical.SingleTestExecutor.executeSafely(SingleTestExecutor.java:66) at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.executeRecursively(HierarchicalTestExecutor.java:108) at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.execute(HierarchicalTestExecutor.java:79) at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$2(HierarchicalTestExecutor.java:120) at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184) at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175) at java.util.Iterator.forEachRemaining(Iterator.java:116) at java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801) at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151) at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174) at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418) at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$3(HierarchicalTestExecutor.java:120) at org.junit.platform.engine.support.hierarchical.SingleTestExecutor.executeSafely(SingleTestExecutor.java:66) at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.executeRecursively(HierarchicalTestExecutor.java:108) at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.execute(HierarchicalTestExecutor.java:79) at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$2(HierarchicalTestExecutor.java:120) at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184) at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175) at java.util.Iterator.forEachRemaining(Iterator.java:116) at java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801) at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) at jav
[jira] [Updated] (VELOCITY-896) Regression in the handling of string containing a sharp
[ https://issues.apache.org/jira/browse/VELOCITY-896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mortagne updated VELOCITY-896: - Description: The following produce a ParseErrorException after upgrading to Velocity 2: {code} #set($var = "#") {code} {noformat} org.xwiki.velocity.XWikiVelocityException: Failed to evaluate content with id [mytemplate] at org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:279) at org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:244) at org.xwiki.velocity.internal.DefaultVelocityEngineTest.assertEvaluate(DefaultVelocityEngineTest.java:92) at org.xwiki.velocity.internal.DefaultVelocityEngineTest.assertEvaluate(DefaultVelocityEngineTest.java:85) at org.xwiki.velocity.internal.DefaultVelocityEngineTest.testMisc(DefaultVelocityEngineTest.java:287) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:436) at org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:115) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$6(TestMethodTestDescriptor.java:170) at org.junit.jupiter.engine.execution.ThrowableCollector.execute(ThrowableCollector.java:40) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:166) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:113) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:58) at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$3(HierarchicalTestExecutor.java:112) at org.junit.platform.engine.support.hierarchical.SingleTestExecutor.executeSafely(SingleTestExecutor.java:66) at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.executeRecursively(HierarchicalTestExecutor.java:108) at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.execute(HierarchicalTestExecutor.java:79) at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$2(HierarchicalTestExecutor.java:120) at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184) at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175) at java.util.Iterator.forEachRemaining(Iterator.java:116) at java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801) at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151) at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174) at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418) at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$3(HierarchicalTestExecutor.java:120) at org.junit.platform.engine.support.hierarchical.SingleTestExecutor.executeSafely(SingleTestExecutor.java:66) at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.executeRecursively(HierarchicalTestExecutor.java:108) at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.execute(HierarchicalTestExecutor.java:79) at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$2(HierarchicalTestExecutor.java:120) at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184) at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175) at java.util.Iterator.forEachRemaining(Iterator.java:116) at java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801) at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
[jira] [Updated] (VELOCITY-896) Regression in the handling of string containing a sharp
[ https://issues.apache.org/jira/browse/VELOCITY-896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mortagne updated VELOCITY-896: - Description: The following produce a ParseErrorException after upgrading to Velocity 2: {code} #set($var = "#") {code} {noformat} org.xwiki.velocity.XWikiVelocityException: Failed to evaluate content with id [mytemplate] at org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:279) at org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:244) at org.xwiki.velocity.internal.DefaultVelocityEngineTest.assertEvaluate(DefaultVelocityEngineTest.java:92) at org.xwiki.velocity.internal.DefaultVelocityEngineTest.assertEvaluate(DefaultVelocityEngineTest.java:85) at org.xwiki.velocity.internal.DefaultVelocityEngineTest.testMisc(DefaultVelocityEngineTest.java:287) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:436) at org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:115) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$6(TestMethodTestDescriptor.java:170) at org.junit.jupiter.engine.execution.ThrowableCollector.execute(ThrowableCollector.java:40) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:166) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:113) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:58) at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$3(HierarchicalTestExecutor.java:112) at org.junit.platform.engine.support.hierarchical.SingleTestExecutor.executeSafely(SingleTestExecutor.java:66) at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.executeRecursively(HierarchicalTestExecutor.java:108) at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.execute(HierarchicalTestExecutor.java:79) at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$2(HierarchicalTestExecutor.java:120) at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184) at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175) at java.util.Iterator.forEachRemaining(Iterator.java:116) at java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801) at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151) at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174) at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418) at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$3(HierarchicalTestExecutor.java:120) at org.junit.platform.engine.support.hierarchical.SingleTestExecutor.executeSafely(SingleTestExecutor.java:66) at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.executeRecursively(HierarchicalTestExecutor.java:108) at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.execute(HierarchicalTestExecutor.java:79) at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$2(HierarchicalTestExecutor.java:120) at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184) at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175) at java.util.Iterator.forEachRemaining(Iterator.java:116) at java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801) at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
[jira] [Updated] (VELOCITY-896) Regression in the handling of String literal ending with a sharp
[ https://issues.apache.org/jira/browse/VELOCITY-896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mortagne updated VELOCITY-896: - Description: The following produce a ParseErrorException after upgrading to Velocity 2: {code} #set($var = "#") {code} or {code} #set($var = "toto#") {code} {noformat} org.xwiki.velocity.XWikiVelocityException: Failed to evaluate content with id [mytemplate] at org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:279) at org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:244) at org.xwiki.velocity.internal.DefaultVelocityEngineTest.assertEvaluate(DefaultVelocityEngineTest.java:92) at org.xwiki.velocity.internal.DefaultVelocityEngineTest.assertEvaluate(DefaultVelocityEngineTest.java:85) at org.xwiki.velocity.internal.DefaultVelocityEngineTest.testMisc(DefaultVelocityEngineTest.java:287) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:436) at org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:115) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$6(TestMethodTestDescriptor.java:170) at org.junit.jupiter.engine.execution.ThrowableCollector.execute(ThrowableCollector.java:40) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:166) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:113) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:58) at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$3(HierarchicalTestExecutor.java:112) at org.junit.platform.engine.support.hierarchical.SingleTestExecutor.executeSafely(SingleTestExecutor.java:66) at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.executeRecursively(HierarchicalTestExecutor.java:108) at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.execute(HierarchicalTestExecutor.java:79) at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$2(HierarchicalTestExecutor.java:120) at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184) at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175) at java.util.Iterator.forEachRemaining(Iterator.java:116) at java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801) at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151) at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174) at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418) at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$3(HierarchicalTestExecutor.java:120) at org.junit.platform.engine.support.hierarchical.SingleTestExecutor.executeSafely(SingleTestExecutor.java:66) at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.executeRecursively(HierarchicalTestExecutor.java:108) at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.execute(HierarchicalTestExecutor.java:79) at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$2(HierarchicalTestExecutor.java:120) at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184) at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175) at java.util.Iterator.forEachRemaining(Iterator.java:116) at java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801) at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) at java.util.stream.ForEachOps$ForEachOp
[jira] [Updated] (VELOCITY-896) Regression in the handling of String literal ending with a sharp
[ https://issues.apache.org/jira/browse/VELOCITY-896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mortagne updated VELOCITY-896: - Summary: Regression in the handling of String literal ending with a sharp (was: Regression in the handling of string containing a sharp) > Regression in the handling of String literal ending with a sharp > > > Key: VELOCITY-896 > URL: https://issues.apache.org/jira/browse/VELOCITY-896 > Project: Velocity > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Thomas Mortagne >Priority: Blocker > > The following produce a ParseErrorException after upgrading to Velocity 2: > {code} > #set($var = "#") > {code} > {noformat} > org.xwiki.velocity.XWikiVelocityException: Failed to evaluate content with id > [mytemplate] > at > org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:279) > at > org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:244) > at > org.xwiki.velocity.internal.DefaultVelocityEngineTest.assertEvaluate(DefaultVelocityEngineTest.java:92) > at > org.xwiki.velocity.internal.DefaultVelocityEngineTest.assertEvaluate(DefaultVelocityEngineTest.java:85) > at > org.xwiki.velocity.internal.DefaultVelocityEngineTest.testMisc(DefaultVelocityEngineTest.java:287) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:436) > at > org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:115) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$6(TestMethodTestDescriptor.java:170) > at > org.junit.jupiter.engine.execution.ThrowableCollector.execute(ThrowableCollector.java:40) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:166) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:113) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:58) > at > org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$3(HierarchicalTestExecutor.java:112) > at > org.junit.platform.engine.support.hierarchical.SingleTestExecutor.executeSafely(SingleTestExecutor.java:66) > at > org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.executeRecursively(HierarchicalTestExecutor.java:108) > at > org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.execute(HierarchicalTestExecutor.java:79) > at > org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$2(HierarchicalTestExecutor.java:120) > at > java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184) > at > java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175) > at java.util.Iterator.forEachRemaining(Iterator.java:116) > at > java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801) > at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) > at > java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) > at > java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151) > at > java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174) > at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) > at > java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418) > at > org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$3(HierarchicalTestExecutor.java:120) > at > org.junit.platform.engine.support.hierarchical.SingleTestExecutor.executeSafely(SingleTestExecutor.java:66) > at > org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.executeRecursively(HierarchicalTestExecutor.java:108) > at > org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.execute(HierarchicalTestExecutor.java:79) > at > org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$2(HierarchicalTestExecuto
[jira] [Updated] (VELOCITY-896) Regression in the handling of String literal ending with a sharp sign
[ https://issues.apache.org/jira/browse/VELOCITY-896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mortagne updated VELOCITY-896: - Summary: Regression in the handling of String literal ending with a sharp sign (was: Regression in the handling of String literal ending with a sharp) > Regression in the handling of String literal ending with a sharp sign > - > > Key: VELOCITY-896 > URL: https://issues.apache.org/jira/browse/VELOCITY-896 > Project: Velocity > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Thomas Mortagne >Priority: Blocker > > The following produce a ParseErrorException after upgrading to Velocity 2: > {code} > #set($var = "#") > {code} > or > {code} > #set($var = "toto#") > {code} > {noformat} > org.xwiki.velocity.XWikiVelocityException: Failed to evaluate content with id > [mytemplate] > at > org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:279) > at > org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:244) > at > org.xwiki.velocity.internal.DefaultVelocityEngineTest.assertEvaluate(DefaultVelocityEngineTest.java:92) > at > org.xwiki.velocity.internal.DefaultVelocityEngineTest.assertEvaluate(DefaultVelocityEngineTest.java:85) > at > org.xwiki.velocity.internal.DefaultVelocityEngineTest.testMisc(DefaultVelocityEngineTest.java:287) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:436) > at > org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:115) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$6(TestMethodTestDescriptor.java:170) > at > org.junit.jupiter.engine.execution.ThrowableCollector.execute(ThrowableCollector.java:40) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:166) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:113) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:58) > at > org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$3(HierarchicalTestExecutor.java:112) > at > org.junit.platform.engine.support.hierarchical.SingleTestExecutor.executeSafely(SingleTestExecutor.java:66) > at > org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.executeRecursively(HierarchicalTestExecutor.java:108) > at > org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.execute(HierarchicalTestExecutor.java:79) > at > org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$2(HierarchicalTestExecutor.java:120) > at > java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184) > at > java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175) > at java.util.Iterator.forEachRemaining(Iterator.java:116) > at > java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801) > at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) > at > java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) > at > java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151) > at > java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174) > at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) > at > java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418) > at > org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$3(HierarchicalTestExecutor.java:120) > at > org.junit.platform.engine.support.hierarchical.SingleTestExecutor.executeSafely(SingleTestExecutor.java:66) > at > org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.executeRecursively(HierarchicalTestExecutor.java:108) > at > org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.execute(HierarchicalTestExecutor.java:79) > at > org.junit.platform.engine.support.hierarchical.HierarchicalTestEx
[jira] [Created] (VELOCITY-897) Regression in the handling of String literal ending with a dollar sign
Thomas Mortagne created VELOCITY-897: Summary: Regression in the handling of String literal ending with a dollar sign Key: VELOCITY-897 URL: https://issues.apache.org/jira/browse/VELOCITY-897 Project: Velocity Issue Type: Bug Affects Versions: 2.0 Reporter: Thomas Mortagne Same as VELOCITY-896 but this time with dollar sign ($). For example {code} #set($var = "$") {code} or {code} #set($var = "toto$") {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-896) Regression in the handling of String literal ending with a sharp sign
[ https://issues.apache.org/jira/browse/VELOCITY-896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mortagne updated VELOCITY-896: - Description: The following produce a ParseErrorException after upgrading to Velocity 2: {code} #set($var = "#") {code} or {code} #set($var = "toto#") {code} {noformat} org.xwiki.velocity.XWikiVelocityException: Failed to evaluate content with id [mytemplate] at org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:279) at org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:244) at org.xwiki.velocity.internal.DefaultVelocityEngineTest.assertEvaluate(DefaultVelocityEngineTest.java:92) at org.xwiki.velocity.internal.DefaultVelocityEngineTest.assertEvaluate(DefaultVelocityEngineTest.java:85) at org.xwiki.velocity.internal.DefaultVelocityEngineTest.testMisc(DefaultVelocityEngineTest.java:287) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:436) at org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:115) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$6(TestMethodTestDescriptor.java:170) at org.junit.jupiter.engine.execution.ThrowableCollector.execute(ThrowableCollector.java:40) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:166) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:113) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:58) at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$3(HierarchicalTestExecutor.java:112) at org.junit.platform.engine.support.hierarchical.SingleTestExecutor.executeSafely(SingleTestExecutor.java:66) at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.executeRecursively(HierarchicalTestExecutor.java:108) at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.execute(HierarchicalTestExecutor.java:79) at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$2(HierarchicalTestExecutor.java:120) at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184) at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175) at java.util.Iterator.forEachRemaining(Iterator.java:116) at java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801) at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151) at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174) at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418) at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$3(HierarchicalTestExecutor.java:120) at org.junit.platform.engine.support.hierarchical.SingleTestExecutor.executeSafely(SingleTestExecutor.java:66) at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.executeRecursively(HierarchicalTestExecutor.java:108) at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.execute(HierarchicalTestExecutor.java:79) at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$2(HierarchicalTestExecutor.java:120) at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184) at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175) at java.util.Iterator.forEachRemaining(Iterator.java:116) at java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801) at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) at java.util.stream.ForEachOps$ForEachOp
[jira] [Comment Edited] (VELOCITY-900) Velocity.evalute thows an exception if the next char after a keyword is '_'
[ https://issues.apache.org/jira/browse/VELOCITY-900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16605622#comment-16605622 ] Thomas Mortagne edited comment on VELOCITY-900 at 9/6/18 10:46 AM: --- This is probably because Velocity thinks you are trying to call the directive "end__" since _ is valid in a directive name. You can workaround it by using {noformat}#{end}{noformat}. was (Author: tmortagne): This is probably because Velocity thinks you are trying to call the directive "end__" since _ is valid in a directive name. You can workaround it by using {{#{end}}}. > Velocity.evalute thows an exception if the next char after a keyword is '_' > --- > > Key: VELOCITY-900 > URL: https://issues.apache.org/jira/browse/VELOCITY-900 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.0 > Environment: Win 7, Java 8 >Reporter: Alto >Priority: Major > > If I try to evalute the folling template "CONSTRAINT > DF_#if(${archiveTableTemplate})${archiveTableTemplate}#else${table}#end__${column}" > an exception is thrown. > Velocity.evaluate(myContext, myStringWriter, "LOG", template); = >Exception > occurred in target VM: Encountered "" at LOG[line 1, column 93] > Was expecting one of: > "(" ... > ")" ... > ... > "]]#" ... > ... > ... > ... > ... > ... > ... > ... > "{" ... > "}" ... > "" ... > "\\" ... > ... > ... > ... > "{" ... > < > If I use the Template "CONSTRAINT > DF_#if(${archiveTableTemplate})${archiveTableTemplate}#else${table}#end > __${column}" it works, but the result is wrong. Blank after replacement. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-900) Velocity.evalute thows an exception if the next char after a keyword is '_'
[ https://issues.apache.org/jira/browse/VELOCITY-900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16605622#comment-16605622 ] Thomas Mortagne commented on VELOCITY-900: -- This is probably because Velocity thinks you are trying to call the directive "end__" since _ is valid in a directive name. You can workaround it by using {{#{end}}}. > Velocity.evalute thows an exception if the next char after a keyword is '_' > --- > > Key: VELOCITY-900 > URL: https://issues.apache.org/jira/browse/VELOCITY-900 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.0 > Environment: Win 7, Java 8 >Reporter: Alto >Priority: Major > > If I try to evalute the folling template "CONSTRAINT > DF_#if(${archiveTableTemplate})${archiveTableTemplate}#else${table}#end__${column}" > an exception is thrown. > Velocity.evaluate(myContext, myStringWriter, "LOG", template); = >Exception > occurred in target VM: Encountered "" at LOG[line 1, column 93] > Was expecting one of: > "(" ... > ")" ... > ... > "]]#" ... > ... > ... > ... > ... > ... > ... > ... > "{" ... > "}" ... > "" ... > "\\" ... > ... > ... > ... > "{" ... > < > If I use the Template "CONSTRAINT > DF_#if(${archiveTableTemplate})${archiveTableTemplate}#else${table}#end > __${column}" it works, but the result is wrong. Blank after replacement. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-900) Velocity.evalute thows an exception if the next char after a keyword is '_'
[ https://issues.apache.org/jira/browse/VELOCITY-900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16605622#comment-16605622 ] Thomas Mortagne edited comment on VELOCITY-900 at 9/6/18 10:46 AM: --- This is probably because Velocity thinks you are trying to call the directive "end__" since _ is valid in a directive name. You can workaround it by using {noformat}#{end}{noformat}. So same logic as the variables. was (Author: tmortagne): This is probably because Velocity thinks you are trying to call the directive "end__" since _ is valid in a directive name. You can workaround it by using {noformat}#{end}{noformat}. > Velocity.evalute thows an exception if the next char after a keyword is '_' > --- > > Key: VELOCITY-900 > URL: https://issues.apache.org/jira/browse/VELOCITY-900 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.0 > Environment: Win 7, Java 8 >Reporter: Alto >Priority: Major > > If I try to evalute the folling template "CONSTRAINT > DF_#if(${archiveTableTemplate})${archiveTableTemplate}#else${table}#end__${column}" > an exception is thrown. > Velocity.evaluate(myContext, myStringWriter, "LOG", template); = >Exception > occurred in target VM: Encountered "" at LOG[line 1, column 93] > Was expecting one of: > "(" ... > ")" ... > ... > "]]#" ... > ... > ... > ... > ... > ... > ... > ... > "{" ... > "}" ... > "" ... > "\\" ... > ... > ... > ... > "{" ... > < > If I use the Template "CONSTRAINT > DF_#if(${archiveTableTemplate})${archiveTableTemplate}#else${table}#end > __${column}" it works, but the result is wrong. Blank after replacement. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-901) hyphen in identifiers cause parse error
[ https://issues.apache.org/jira/browse/VELOCITY-901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16608862#comment-16608862 ] Thomas Mortagne commented on VELOCITY-901: -- This is actually documented in the Velocity 2 release note (http://velocity.apache.org/engine/2.0/upgrading.html) {noformat} * the hypen ( - ) cannot be used in variable names anymore {noformat} But yes I'm not super happy about it either. > hyphen in identifiers cause parse error > --- > > Key: VELOCITY-901 > URL: https://issues.apache.org/jira/browse/VELOCITY-901 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.0 >Reporter: Mark Newton >Priority: Major > Attachments: err, example2.vm.snip, run.sh > > > Upon upgrading to Velocity 2.0 from a very old version (1.4), hyphens in > identifiers in templates throw a ParseException. > To verify what was happening, I did a clean install of velocity 2.0 to test > your example code. After running the unmodified "example2.vm" successfully I > added an identifier with a hyphen and the parse error occurred. > Apologies if I am missing something (e.g. spec change on identifiers). If > this is an issue that will take a while to fix, please let me know so that I > can change out the hyphens to underbars in id's in my template sets. > Attached are: 1) code snippet 2) parse exception msg 3) cl used to invoke > velocity 2.0 upon example2.vm > Best Regards > > 1) code snippet > #set($test-var-w-hyphen = "test") > test-var-w-hyphen : $test-var-w-hyphen > -- > 2) Parse exception > [main] ERROR org.apache.velocity.parser - example2.vm: Encountered "-" at > line 20, column 11. > Was expecting one of: > "[" ... > ... > ... > "=" ... > -- > 3) Command Script > #/bin/bash > java -cp > .:/home/test-a/.ant/lib/commons-lang3-3.8.jar:/home/test-a/.ant/lib/slf4j-api-1.7.25.jar:/home/test-a/.ant/lib/velocity-engine-core-2.0.jar:/home/test-a/.ant/lib/velocity-engine-scripting-2.0.jar:/home/test-a/.ant/lib/slf4j-simple-1.7.25.jar > org.apache.velocity.example.Example2 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-901) hyphen in identifiers cause parse error
[ https://issues.apache.org/jira/browse/VELOCITY-901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16609063#comment-16609063 ] Thomas Mortagne commented on VELOCITY-901: -- bq. his was very confusing for newcomers. Do you really think you want them back?! I agree but on my side the issue is how to deal with retro compatibility. Such a change is a major breakage (even if documented). > hyphen in identifiers cause parse error > --- > > Key: VELOCITY-901 > URL: https://issues.apache.org/jira/browse/VELOCITY-901 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.0 >Reporter: Mark Newton >Priority: Major > Attachments: err, example2.vm.snip, run.sh > > > Upon upgrading to Velocity 2.0 from a very old version (1.4), hyphens in > identifiers in templates throw a ParseException. > To verify what was happening, I did a clean install of velocity 2.0 to test > your example code. After running the unmodified "example2.vm" successfully I > added an identifier with a hyphen and the parse error occurred. > Apologies if I am missing something (e.g. spec change on identifiers). If > this is an issue that will take a while to fix, please let me know so that I > can change out the hyphens to underbars in id's in my template sets. > Attached are: 1) code snippet 2) parse exception msg 3) cl used to invoke > velocity 2.0 upon example2.vm > Best Regards > > 1) code snippet > #set($test-var-w-hyphen = "test") > test-var-w-hyphen : $test-var-w-hyphen > -- > 2) Parse exception > [main] ERROR org.apache.velocity.parser - example2.vm: Encountered "-" at > line 20, column 11. > Was expecting one of: > "[" ... > ... > ... > "=" ... > -- > 3) Command Script > #/bin/bash > java -cp > .:/home/test-a/.ant/lib/commons-lang3-3.8.jar:/home/test-a/.ant/lib/slf4j-api-1.7.25.jar:/home/test-a/.ant/lib/velocity-engine-core-2.0.jar:/home/test-a/.ant/lib/velocity-engine-scripting-2.0.jar:/home/test-a/.ant/lib/slf4j-simple-1.7.25.jar > org.apache.velocity.example.Example2 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-896) Regression in the handling of String literal ending with a sharp sign
[ https://issues.apache.org/jira/browse/VELOCITY-896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16621600#comment-16621600 ] Thomas Mortagne commented on VELOCITY-896: -- [~spbolton] really I don't understand VELOCITY-677. As I indicated in the issue description the examples I gave are working fine in 1.7. If this was already broken in 1.7 then I would not really care, as I said my only concern is retro compatibility. Same thing for VELOCITY-897. > Regression in the handling of String literal ending with a sharp sign > - > > Key: VELOCITY-896 > URL: https://issues.apache.org/jira/browse/VELOCITY-896 > Project: Velocity > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Thomas Mortagne >Priority: Blocker > > The following produce a ParseErrorException after upgrading to Velocity 2: > {code} > #set($var = "#") > {code} > or > {code} > #set($var = "toto#") > {code} > {noformat} > org.xwiki.velocity.XWikiVelocityException: Failed to evaluate content with id > [mytemplate] > at > org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:279) > at > org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:244) > at > org.xwiki.velocity.internal.DefaultVelocityEngineTest.assertEvaluate(DefaultVelocityEngineTest.java:92) > at > org.xwiki.velocity.internal.DefaultVelocityEngineTest.assertEvaluate(DefaultVelocityEngineTest.java:85) > at > org.xwiki.velocity.internal.DefaultVelocityEngineTest.testMisc(DefaultVelocityEngineTest.java:287) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:436) > at > org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:115) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$6(TestMethodTestDescriptor.java:170) > at > org.junit.jupiter.engine.execution.ThrowableCollector.execute(ThrowableCollector.java:40) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:166) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:113) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:58) > at > org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$3(HierarchicalTestExecutor.java:112) > at > org.junit.platform.engine.support.hierarchical.SingleTestExecutor.executeSafely(SingleTestExecutor.java:66) > at > org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.executeRecursively(HierarchicalTestExecutor.java:108) > at > org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.execute(HierarchicalTestExecutor.java:79) > at > org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$2(HierarchicalTestExecutor.java:120) > at > java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184) > at > java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175) > at java.util.Iterator.forEachRemaining(Iterator.java:116) > at > java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801) > at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) > at > java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) > at > java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151) > at > java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174) > at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) > at > java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418) > at > org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$3(HierarchicalTestExecutor.java:120) > at > org.junit.platform.engine.support.hierarchical.SingleTestExecutor.executeSafely(SingleTestExecutor.java:66) > at > org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.executeRecursively(HierarchicalTestExecutor.java:108) > at > org.junit.platform.eng
[jira] [Comment Edited] (VELOCITY-896) Regression in the handling of String literal ending with a sharp sign
[ https://issues.apache.org/jira/browse/VELOCITY-896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16621600#comment-16621600 ] Thomas Mortagne edited comment on VELOCITY-896 at 9/20/18 7:15 AM: --- [~spbolton] really I don't understand how this is a duplicate of VELOCITY-677. As I indicated in the issue description the examples I gave are working fine in 1.7. For me VELOCITY-677 is not related to string literal but to end of the script. If this was already broken in 1.7 then I would not really care, as I said my only concern is retro compatibility. Same thing for VELOCITY-897. was (Author: tmortagne): [~spbolton] really I don't understand VELOCITY-677. As I indicated in the issue description the examples I gave are working fine in 1.7. If this was already broken in 1.7 then I would not really care, as I said my only concern is retro compatibility. Same thing for VELOCITY-897. > Regression in the handling of String literal ending with a sharp sign > - > > Key: VELOCITY-896 > URL: https://issues.apache.org/jira/browse/VELOCITY-896 > Project: Velocity > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Thomas Mortagne >Priority: Blocker > > The following produce a ParseErrorException after upgrading to Velocity 2: > {code} > #set($var = "#") > {code} > or > {code} > #set($var = "toto#") > {code} > {noformat} > org.xwiki.velocity.XWikiVelocityException: Failed to evaluate content with id > [mytemplate] > at > org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:279) > at > org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:244) > at > org.xwiki.velocity.internal.DefaultVelocityEngineTest.assertEvaluate(DefaultVelocityEngineTest.java:92) > at > org.xwiki.velocity.internal.DefaultVelocityEngineTest.assertEvaluate(DefaultVelocityEngineTest.java:85) > at > org.xwiki.velocity.internal.DefaultVelocityEngineTest.testMisc(DefaultVelocityEngineTest.java:287) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:436) > at > org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:115) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$6(TestMethodTestDescriptor.java:170) > at > org.junit.jupiter.engine.execution.ThrowableCollector.execute(ThrowableCollector.java:40) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:166) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:113) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:58) > at > org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$3(HierarchicalTestExecutor.java:112) > at > org.junit.platform.engine.support.hierarchical.SingleTestExecutor.executeSafely(SingleTestExecutor.java:66) > at > org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.executeRecursively(HierarchicalTestExecutor.java:108) > at > org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.execute(HierarchicalTestExecutor.java:79) > at > org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$2(HierarchicalTestExecutor.java:120) > at > java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184) > at > java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175) > at java.util.Iterator.forEachRemaining(Iterator.java:116) > at > java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801) > at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) > at > java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) > at > java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151) > at > java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174) > at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) > at > java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418) >
[jira] [Comment Edited] (VELOCITY-896) Regression in the handling of String literal ending with a sharp sign
[ https://issues.apache.org/jira/browse/VELOCITY-896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16621600#comment-16621600 ] Thomas Mortagne edited comment on VELOCITY-896 at 9/20/18 7:16 AM: --- [~spbolton] really I don't understand how this is a duplicate of VELOCITY-677. As I indicated in the issue description the examples I gave are working fine in 1.7. For me VELOCITY-677 is not related to string literal but to end of the script. If this was already broken in 1.7 then I would not really care, as I said my only concern is retro compatibility. Same thing for VELOCITY-897. Anyway thanks a lot for looking into this ! was (Author: tmortagne): [~spbolton] really I don't understand how this is a duplicate of VELOCITY-677. As I indicated in the issue description the examples I gave are working fine in 1.7. For me VELOCITY-677 is not related to string literal but to end of the script. If this was already broken in 1.7 then I would not really care, as I said my only concern is retro compatibility. Same thing for VELOCITY-897. > Regression in the handling of String literal ending with a sharp sign > - > > Key: VELOCITY-896 > URL: https://issues.apache.org/jira/browse/VELOCITY-896 > Project: Velocity > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Thomas Mortagne >Priority: Blocker > > The following produce a ParseErrorException after upgrading to Velocity 2: > {code} > #set($var = "#") > {code} > or > {code} > #set($var = "toto#") > {code} > {noformat} > org.xwiki.velocity.XWikiVelocityException: Failed to evaluate content with id > [mytemplate] > at > org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:279) > at > org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:244) > at > org.xwiki.velocity.internal.DefaultVelocityEngineTest.assertEvaluate(DefaultVelocityEngineTest.java:92) > at > org.xwiki.velocity.internal.DefaultVelocityEngineTest.assertEvaluate(DefaultVelocityEngineTest.java:85) > at > org.xwiki.velocity.internal.DefaultVelocityEngineTest.testMisc(DefaultVelocityEngineTest.java:287) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:436) > at > org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:115) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$6(TestMethodTestDescriptor.java:170) > at > org.junit.jupiter.engine.execution.ThrowableCollector.execute(ThrowableCollector.java:40) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:166) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:113) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:58) > at > org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$3(HierarchicalTestExecutor.java:112) > at > org.junit.platform.engine.support.hierarchical.SingleTestExecutor.executeSafely(SingleTestExecutor.java:66) > at > org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.executeRecursively(HierarchicalTestExecutor.java:108) > at > org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.execute(HierarchicalTestExecutor.java:79) > at > org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$2(HierarchicalTestExecutor.java:120) > at > java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184) > at > java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175) > at java.util.Iterator.forEachRemaining(Iterator.java:116) > at > java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801) > at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) > at > java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) > at > java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151) > at > java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174) > at java.uti
[jira] [Commented] (VELOCITY-542) minus sign in #set requires spaces to surround it
[ https://issues.apache.org/jira/browse/VELOCITY-542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16621605#comment-16621605 ] Thomas Mortagne commented on VELOCITY-542: -- I strongly agree with [~nate_chadw...@percussion.com]. This makes upgrading to (standard) Velocity 2 a major risk for many existing scripts. I can perfectly understand breakages in the Java API in a new major version but the language retro compatibility is critical IMO. > minus sign in #set requires spaces to surround it > - > > Key: VELOCITY-542 > URL: https://issues.apache.org/jira/browse/VELOCITY-542 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 1.5 >Reporter: Will Glass-Husain >Assignee: Claude Brisson >Priority: Minor > Fix For: 2.0 > > > The following example: > #set($thisCampNumber = 10) > #set($nextCampNumber = $thisCampNumber+1) > #set($previousCampNumber = $thisCampNumber-1) > #set($previousCampNumberB = $thisCampNumber - 1) > 1: $thisCampNumber > 2: $nextCampNumber > 3: $previousCampNumber > 4: $previousCampNumberB > produces this result > 1: 10 > 2: 11 > 3: $previousCampNumber > 4: 9 > Note that using a minus sign in a #set statement does not work if there are > no spaces around it. (however, the same is not true for +). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-542) minus sign in #set requires spaces to surround it
[ https://issues.apache.org/jira/browse/VELOCITY-542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16621819#comment-16621819 ] Thomas Mortagne commented on VELOCITY-542: -- bq. But it doesn't stop us from allowing a backward compatibility option An option is perfectly fine for me (would not be the first anyway). bq. What were those other changes? On my side the main other change for which I would love to get retro compatible options is the change in the way to handle macro parameters which change the following behavior: {code} #macro(testmacro $parameter) $parameter #end #testmacro($return) {code} which used to print "$return" (when $return is null or undefined) and we now get "$parameter". Unfortunately I found quite a few scripts in the context of XWiki which count on the old behavior for various reasons (main one being to have a macro "return" a value by changing the value of the passed variable but it's not possible to know that variable name anymore). It's definitely a hack but one which is unfortunately used a lot when you need a macro to return something else than a String. There is also the following which feel more like bugs than the intended behaviors: * https://issues.apache.org/jira/browse/VELOCITY-896 * https://issues.apache.org/jira/browse/VELOCITY-897 > minus sign in #set requires spaces to surround it > - > > Key: VELOCITY-542 > URL: https://issues.apache.org/jira/browse/VELOCITY-542 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 1.5 >Reporter: Will Glass-Husain >Assignee: Claude Brisson >Priority: Minor > Fix For: 2.0 > > > The following example: > #set($thisCampNumber = 10) > #set($nextCampNumber = $thisCampNumber+1) > #set($previousCampNumber = $thisCampNumber-1) > #set($previousCampNumberB = $thisCampNumber - 1) > 1: $thisCampNumber > 2: $nextCampNumber > 3: $previousCampNumber > 4: $previousCampNumberB > produces this result > 1: 10 > 2: 11 > 3: $previousCampNumber > 4: 9 > Note that using a minus sign in a #set statement does not work if there are > no spaces around it. (however, the same is not true for +). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-896) Regression in the handling of String literal ending with a sharp sign
[ https://issues.apache.org/jira/browse/VELOCITY-896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16641730#comment-16641730 ] Thomas Mortagne commented on VELOCITY-896: -- bq. Fixed by commit 1843128. Thanks ! > Regression in the handling of String literal ending with a sharp sign > - > > Key: VELOCITY-896 > URL: https://issues.apache.org/jira/browse/VELOCITY-896 > Project: Velocity > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Thomas Mortagne >Assignee: Claude Brisson >Priority: Blocker > Fix For: 2.1 > > > The following produce a ParseErrorException after upgrading to Velocity 2: > {code} > #set($var = "#") > {code} > or > {code} > #set($var = "toto#") > {code} > {noformat} > org.xwiki.velocity.XWikiVelocityException: Failed to evaluate content with id > [mytemplate] > at > org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:279) > at > org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:244) > at > org.xwiki.velocity.internal.DefaultVelocityEngineTest.assertEvaluate(DefaultVelocityEngineTest.java:92) > at > org.xwiki.velocity.internal.DefaultVelocityEngineTest.assertEvaluate(DefaultVelocityEngineTest.java:85) > at > org.xwiki.velocity.internal.DefaultVelocityEngineTest.testMisc(DefaultVelocityEngineTest.java:287) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:436) > at > org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:115) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$6(TestMethodTestDescriptor.java:170) > at > org.junit.jupiter.engine.execution.ThrowableCollector.execute(ThrowableCollector.java:40) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:166) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:113) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:58) > at > org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$3(HierarchicalTestExecutor.java:112) > at > org.junit.platform.engine.support.hierarchical.SingleTestExecutor.executeSafely(SingleTestExecutor.java:66) > at > org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.executeRecursively(HierarchicalTestExecutor.java:108) > at > org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.execute(HierarchicalTestExecutor.java:79) > at > org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$2(HierarchicalTestExecutor.java:120) > at > java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184) > at > java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175) > at java.util.Iterator.forEachRemaining(Iterator.java:116) > at > java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801) > at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) > at > java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) > at > java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151) > at > java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174) > at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) > at > java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418) > at > org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$3(HierarchicalTestExecutor.java:120) > at > org.junit.platform.engine.support.hierarchical.SingleTestExecutor.executeSafely(SingleTestExecutor.java:66) > at > org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.executeRecursively(HierarchicalTestExecutor.java:108) > at > org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.execute(HierarchicalTestExecutor.java:79) > at > org.junit.platform.engine.support.hierarchical.Hierarchic
[jira] [Commented] (VELOCITY-892) Method arguments conversions should be based on Type instead of Class
[ https://issues.apache.org/jira/browse/VELOCITY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16650084#comment-16650084 ] Thomas Mortagne commented on VELOCITY-892: -- I'm not really talking about having two methods in the same class but simply having methods taking something else than List or List as parameter. Imagine the following use case: {quote} public void foo(List parameter) { for (Integer value : parameter) { // do stuff with the integer } } {quote} {quote} $obj.foo("1, 2, 3, 4, 5") {quote} It's impossible for the converter to know it should convert each element of the list to Integer so at best you will write a converter which produce a List and the method will crash with a ClassCastException. > Method arguments conversions should be based on Type instead of Class > - > > Key: VELOCITY-892 > URL: https://issues.apache.org/jira/browse/VELOCITY-892 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.0 >Reporter: Thomas Mortagne >Priority: Major > Fix For: 2.0 > > > I was happy to see that method arguments conversion has been added to 2.0 so > that I can remove the uberspector we have on XWiki side but unfortunately > ConversionHandler is limited to classes which is way too restrictive for us > (for example if the parameter type is List it won't do the same thing > than if the type is List). > Our uberspector can be found on > https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodArgumentsUberspector.java > to see what we do exactly. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-892) Method arguments conversions should be based on Type instead of Class
[ https://issues.apache.org/jira/browse/VELOCITY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16650084#comment-16650084 ] Thomas Mortagne edited comment on VELOCITY-892 at 10/15/18 11:16 AM: - I'm not really talking about having two methods in the same class but simply having methods taking something else than List or List as parameter. Imagine the following use case: {code} public void foo(List parameter) { for (Integer value : parameter) { // do stuff with the integer } } {code} {code} $obj.foo("1, 2, 3, 4, 5") {code} It's impossible for the converter to know it should convert each element of the list to Integer so at best you will write a converter which produce a List and the method will crash with a ClassCastException. was (Author: tmortagne): I'm not really talking about having two methods in the same class but simply having methods taking something else than List or List as parameter. Imagine the following use case: {quote} public void foo(List parameter) { for (Integer value : parameter) { // do stuff with the integer } } {quote} {quote} $obj.foo("1, 2, 3, 4, 5") {quote} It's impossible for the converter to know it should convert each element of the list to Integer so at best you will write a converter which produce a List and the method will crash with a ClassCastException. > Method arguments conversions should be based on Type instead of Class > - > > Key: VELOCITY-892 > URL: https://issues.apache.org/jira/browse/VELOCITY-892 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.0 >Reporter: Thomas Mortagne >Priority: Major > Fix For: 2.0 > > > I was happy to see that method arguments conversion has been added to 2.0 so > that I can remove the uberspector we have on XWiki side but unfortunately > ConversionHandler is limited to classes which is way too restrictive for us > (for example if the parameter type is List it won't do the same thing > than if the type is List). > Our uberspector can be found on > https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodArgumentsUberspector.java > to see what we do exactly. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-542) minus sign in #set requires spaces to surround it
[ https://issues.apache.org/jira/browse/VELOCITY-542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16650602#comment-16650602 ] Thomas Mortagne commented on VELOCITY-542: -- OK thanks [~claude] ! > minus sign in #set requires spaces to surround it > - > > Key: VELOCITY-542 > URL: https://issues.apache.org/jira/browse/VELOCITY-542 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 1.5 >Reporter: Will Glass-Husain >Assignee: Claude Brisson >Priority: Minor > Fix For: 2.1 > > > The following example: > #set($thisCampNumber = 10) > #set($nextCampNumber = $thisCampNumber+1) > #set($previousCampNumber = $thisCampNumber-1) > #set($previousCampNumberB = $thisCampNumber - 1) > 1: $thisCampNumber > 2: $nextCampNumber > 3: $previousCampNumber > 4: $previousCampNumberB > produces this result > 1: 10 > 2: 11 > 3: $previousCampNumber > 4: 9 > Note that using a minus sign in a #set statement does not work if there are > no spaces around it. (however, the same is not true for +). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-892) Method arguments conversions should be based on Type instead of Class
[ https://issues.apache.org/jira/browse/VELOCITY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16651842#comment-16651842 ] Thomas Mortagne commented on VELOCITY-892: -- bq. Basically, you need to be able to define several converters, String -> List, String -> List , String -> List, ... Yes. bq. Would any of the proposed workarounds fit your case? Otherwise, may I ask, is this feature used a lot? Type with generics are used a lot in input in XWiki yes. bq. Basically, I'm not even sure that this conversion does deserve to be implicit. After all, the separator can vary, there can be beginning and ending normal/square/curly brackets, or other parsing issue... I gave List as an example because it's well know type but it's the same for many other types. bq. Would any of the proposed workarounds fit your case? Otherwise, may I ask, is this feature used a lot? No because we have this feature since a long time and it's used already. Having Type instead of Class in the API does not make much difference for Velocity and give more power to the converter so I don't really see what is the issue exactly. It's really not a blocker since it's not like it was super hard to maintain our uberspector but it's a pity to not have a better API at Velocity level. > Method arguments conversions should be based on Type instead of Class > - > > Key: VELOCITY-892 > URL: https://issues.apache.org/jira/browse/VELOCITY-892 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.0 >Reporter: Thomas Mortagne >Priority: Major > Fix For: 2.0 > > > I was happy to see that method arguments conversion has been added to 2.0 so > that I can remove the uberspector we have on XWiki side but unfortunately > ConversionHandler is limited to classes which is way too restrictive for us > (for example if the parameter type is List it won't do the same thing > than if the type is List). > Our uberspector can be found on > https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodArgumentsUberspector.java > to see what we do exactly. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-892) Method arguments conversions should be based on Type instead of Class
[ https://issues.apache.org/jira/browse/VELOCITY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16653111#comment-16653111 ] Thomas Mortagne edited comment on VELOCITY-892 at 10/17/18 7:22 AM: bq. because it's painful to have the API evolve Yeah always a pain. One possibility I guess is having two kind of converters and call one after the other but yes never nice to have to support the one you don't want people to use anymore. Thanks for taking this into consideration ! was (Author: tmortagne): bq. because it's painful to have the API evolve Yeah always a pain. One possibility I guess is having two kind of converters and call one after the other but yes never nice to have to support the one you don't want people to use anymore. > Method arguments conversions should be based on Type instead of Class > - > > Key: VELOCITY-892 > URL: https://issues.apache.org/jira/browse/VELOCITY-892 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.0 >Reporter: Thomas Mortagne >Priority: Major > Fix For: 2.0 > > > I was happy to see that method arguments conversion has been added to 2.0 so > that I can remove the uberspector we have on XWiki side but unfortunately > ConversionHandler is limited to classes which is way too restrictive for us > (for example if the parameter type is List it won't do the same thing > than if the type is List). > Our uberspector can be found on > https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodArgumentsUberspector.java > to see what we do exactly. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-892) Method arguments conversions should be based on Type instead of Class
[ https://issues.apache.org/jira/browse/VELOCITY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16653111#comment-16653111 ] Thomas Mortagne commented on VELOCITY-892: -- bq. because it's painful to have the API evolve Yeah always a pain. One possibility I guess is having two kind of converters and call one after the other but yes never nice to have to support the one you don't want people to use anymore. > Method arguments conversions should be based on Type instead of Class > - > > Key: VELOCITY-892 > URL: https://issues.apache.org/jira/browse/VELOCITY-892 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.0 >Reporter: Thomas Mortagne >Priority: Major > Fix For: 2.0 > > > I was happy to see that method arguments conversion has been added to 2.0 so > that I can remove the uberspector we have on XWiki side but unfortunately > ConversionHandler is limited to classes which is way too restrictive for us > (for example if the parameter type is List it won't do the same thing > than if the type is List). > Our uberspector can be found on > https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodArgumentsUberspector.java > to see what we do exactly. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-892) Method arguments conversions should be based on Type instead of Class
[ https://issues.apache.org/jira/browse/VELOCITY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16653786#comment-16653786 ] Thomas Mortagne commented on VELOCITY-892: -- Actually my plan was to implement a ConversionHandler and not add a set of converters since XWiki already have a conversion system which is used in https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodArgumentsUberspector.java for example. > Method arguments conversions should be based on Type instead of Class > - > > Key: VELOCITY-892 > URL: https://issues.apache.org/jira/browse/VELOCITY-892 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.0 >Reporter: Thomas Mortagne >Priority: Major > Fix For: 2.0 > > > I was happy to see that method arguments conversion has been added to 2.0 so > that I can remove the uberspector we have on XWiki side but unfortunately > ConversionHandler is limited to classes which is way too restrictive for us > (for example if the parameter type is List it won't do the same thing > than if the type is List). > Our uberspector can be found on > https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodArgumentsUberspector.java > to see what we do exactly. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-892) Method arguments conversions should be based on Type instead of Class
[ https://issues.apache.org/jira/browse/VELOCITY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16653786#comment-16653786 ] Thomas Mortagne edited comment on VELOCITY-892 at 10/17/18 4:20 PM: Actually my plan was to implement a ConversionHandler and not add a set of converters since XWiki already have a conversion system which is used in https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodArgumentsUberspector.java for example. So my issue is more with #getNeededConverter being asked a Class instead of a Type. was (Author: tmortagne): Actually my plan was to implement a ConversionHandler and not add a set of converters since XWiki already have a conversion system which is used in https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodArgumentsUberspector.java for example. > Method arguments conversions should be based on Type instead of Class > - > > Key: VELOCITY-892 > URL: https://issues.apache.org/jira/browse/VELOCITY-892 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.0 >Reporter: Thomas Mortagne >Priority: Major > Fix For: 2.0 > > > I was happy to see that method arguments conversion has been added to 2.0 so > that I can remove the uberspector we have on XWiki side but unfortunately > ConversionHandler is limited to classes which is way too restrictive for us > (for example if the parameter type is List it won't do the same thing > than if the type is List). > Our uberspector can be found on > https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodArgumentsUberspector.java > to see what we do exactly. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-892) Method arguments conversions should be based on Type instead of Class
[ https://issues.apache.org/jira/browse/VELOCITY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16653786#comment-16653786 ] Thomas Mortagne edited comment on VELOCITY-892 at 10/17/18 4:29 PM: Actually my plan was to implement a ConversionHandler and not add a set of converters since XWiki already have a conversion system which is used in https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodArgumentsUberspector.java for example. So my issue is more with #getNeededConverter being asked a Class instead of a Type. Note that in our uberspector the logic is a bit different, if it does not find any matching method it directly try to convert the parameters for each method until it find one for which the conversion did not failed. For example even if there is a Converter available for Integer, the passed String might not actually be a number in which case the conversion will fail and it will try another method which expect some enum and this time it works fine. This is because our converter support really quite a lot of types which mean asking if a converter exist for a type does not give much information for the purpose of parameters conversion. was (Author: tmortagne): Actually my plan was to implement a ConversionHandler and not add a set of converters since XWiki already have a conversion system which is used in https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodArgumentsUberspector.java for example. So my issue is more with #getNeededConverter being asked a Class instead of a Type. > Method arguments conversions should be based on Type instead of Class > - > > Key: VELOCITY-892 > URL: https://issues.apache.org/jira/browse/VELOCITY-892 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.0 >Reporter: Thomas Mortagne >Priority: Major > Fix For: 2.0 > > > I was happy to see that method arguments conversion has been added to 2.0 so > that I can remove the uberspector we have on XWiki side but unfortunately > ConversionHandler is limited to classes which is way too restrictive for us > (for example if the parameter type is List it won't do the same thing > than if the type is List). > Our uberspector can be found on > https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodArgumentsUberspector.java > to see what we do exactly. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-892) Method arguments conversions should be based on Type instead of Class
[ https://issues.apache.org/jira/browse/VELOCITY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16654029#comment-16654029 ] Thomas Mortagne edited comment on VELOCITY-892 at 10/17/18 6:40 PM: bq. Well, to my mind, whether Velocity is Type-aware I never suggested that Velocity should not be Type aware. I'm just saying that there is two different levels: * provide a custom converter handler * provide custom converters to the default converter handler was (Author: tmortagne): bq. Well, to my mind, whether Velocity is Type-aware I never suggested that Velocity should not be Type aware. I'm just saying that there is two different levels: * provider a custom converter handler * provider custom converters to the default converter handler > Method arguments conversions should be based on Type instead of Class > - > > Key: VELOCITY-892 > URL: https://issues.apache.org/jira/browse/VELOCITY-892 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.0 >Reporter: Thomas Mortagne >Priority: Major > Fix For: 2.0 > > > I was happy to see that method arguments conversion has been added to 2.0 so > that I can remove the uberspector we have on XWiki side but unfortunately > ConversionHandler is limited to classes which is way too restrictive for us > (for example if the parameter type is List it won't do the same thing > than if the type is List). > Our uberspector can be found on > https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodArgumentsUberspector.java > to see what we do exactly. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-892) Method arguments conversions should be based on Type instead of Class
[ https://issues.apache.org/jira/browse/VELOCITY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16654029#comment-16654029 ] Thomas Mortagne commented on VELOCITY-892: -- bq. Well, to my mind, whether Velocity is Type-aware I never suggested that Velocity should not be Type aware. I'm just saying that there is two different levels: * provider a custom converter handler * provider custom converters to the default converter handler > Method arguments conversions should be based on Type instead of Class > - > > Key: VELOCITY-892 > URL: https://issues.apache.org/jira/browse/VELOCITY-892 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.0 >Reporter: Thomas Mortagne >Priority: Major > Fix For: 2.0 > > > I was happy to see that method arguments conversion has been added to 2.0 so > that I can remove the uberspector we have on XWiki side but unfortunately > ConversionHandler is limited to classes which is way too restrictive for us > (for example if the parameter type is List it won't do the same thing > than if the type is List). > Our uberspector can be found on > https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodArgumentsUberspector.java > to see what we do exactly. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-892) Method arguments conversions should be based on Type instead of Class
[ https://issues.apache.org/jira/browse/VELOCITY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16654029#comment-16654029 ] Thomas Mortagne edited comment on VELOCITY-892 at 10/17/18 6:43 PM: bq. Well, to my mind, whether Velocity is Type-aware I never suggested that Velocity should not be Type aware. I'm just saying that there is two different levels: * provide a custom converter handler * provide custom converters to the default converter handler Just trying to make sure that I will be able to cover all XWiki use cases with the new APIs provided by Velocity. Since current system is working well I don't want to spend a lot of time on refactoring it to break things basically. was (Author: tmortagne): bq. Well, to my mind, whether Velocity is Type-aware I never suggested that Velocity should not be Type aware. I'm just saying that there is two different levels: * provide a custom converter handler * provide custom converters to the default converter handler > Method arguments conversions should be based on Type instead of Class > - > > Key: VELOCITY-892 > URL: https://issues.apache.org/jira/browse/VELOCITY-892 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.0 >Reporter: Thomas Mortagne >Priority: Major > Fix For: 2.0 > > > I was happy to see that method arguments conversion has been added to 2.0 so > that I can remove the uberspector we have on XWiki side but unfortunately > ConversionHandler is limited to classes which is way too restrictive for us > (for example if the parameter type is List it won't do the same thing > than if the type is List). > Our uberspector can be found on > https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodArgumentsUberspector.java > to see what we do exactly. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-892) Method arguments conversions should be based on Type instead of Class
[ https://issues.apache.org/jira/browse/VELOCITY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16654872#comment-16654872 ] Thomas Mortagne commented on VELOCITY-892: -- > And you can give Velocity the former (now deprecated in the branch) > ConversionHandler or the new one in the runtime.conversion.handler.class > property. Is there any alternative programmatic way to pass a Java instance instead ? Otherwise I will have to store some stuff in a static for the XWikiTypeConversionHandler constructor to access it when it's called by Velocity. > Method arguments conversions should be based on Type instead of Class > - > > Key: VELOCITY-892 > URL: https://issues.apache.org/jira/browse/VELOCITY-892 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.0 >Reporter: Thomas Mortagne >Priority: Major > Fix For: 2.0 > > > I was happy to see that method arguments conversion has been added to 2.0 so > that I can remove the uberspector we have on XWiki side but unfortunately > ConversionHandler is limited to classes which is way too restrictive for us > (for example if the parameter type is List it won't do the same thing > than if the type is List). > Our uberspector can be found on > https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodArgumentsUberspector.java > to see what we do exactly. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-892) Method arguments conversions should be based on Type instead of Class
[ https://issues.apache.org/jira/browse/VELOCITY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16654872#comment-16654872 ] Thomas Mortagne edited comment on VELOCITY-892 at 10/18/18 8:41 AM: bq. And you can give Velocity the former (now deprecated in the branch) ConversionHandler or the new one in the runtime.conversion.handler.class property. Is there any alternative programmatic way to pass a Java instance instead ? Otherwise I will have to store some stuff in a static for the XWikiTypeConversionHandler constructor to access it when it's called by Velocity. was (Author: tmortagne): > And you can give Velocity the former (now deprecated in the branch) > ConversionHandler or the new one in the runtime.conversion.handler.class > property. Is there any alternative programmatic way to pass a Java instance instead ? Otherwise I will have to store some stuff in a static for the XWikiTypeConversionHandler constructor to access it when it's called by Velocity. > Method arguments conversions should be based on Type instead of Class > - > > Key: VELOCITY-892 > URL: https://issues.apache.org/jira/browse/VELOCITY-892 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.0 >Reporter: Thomas Mortagne >Priority: Major > Fix For: 2.0 > > > I was happy to see that method arguments conversion has been added to 2.0 so > that I can remove the uberspector we have on XWiki side but unfortunately > ConversionHandler is limited to classes which is way too restrictive for us > (for example if the parameter type is List it won't do the same thing > than if the type is List). > Our uberspector can be found on > https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodArgumentsUberspector.java > to see what we do exactly. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-896) Regression in the handling of String literal ending with a sharp sign
[ https://issues.apache.org/jira/browse/VELOCITY-896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16732170#comment-16732170 ] Thomas Mortagne commented on VELOCITY-896: -- [~claude] any idea when 2.1 release is planned ? > Regression in the handling of String literal ending with a sharp sign > - > > Key: VELOCITY-896 > URL: https://issues.apache.org/jira/browse/VELOCITY-896 > Project: Velocity > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Thomas Mortagne >Assignee: Claude Brisson >Priority: Blocker > Fix For: 2.1 > > > The following produce a ParseErrorException after upgrading to Velocity 2: > {code} > #set($var = "#") > {code} > or > {code} > #set($var = "toto#") > {code} > {noformat} > org.xwiki.velocity.XWikiVelocityException: Failed to evaluate content with id > [mytemplate] > at > org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:279) > at > org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:244) > at > org.xwiki.velocity.internal.DefaultVelocityEngineTest.assertEvaluate(DefaultVelocityEngineTest.java:92) > at > org.xwiki.velocity.internal.DefaultVelocityEngineTest.assertEvaluate(DefaultVelocityEngineTest.java:85) > at > org.xwiki.velocity.internal.DefaultVelocityEngineTest.testMisc(DefaultVelocityEngineTest.java:287) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:436) > at > org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:115) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$6(TestMethodTestDescriptor.java:170) > at > org.junit.jupiter.engine.execution.ThrowableCollector.execute(ThrowableCollector.java:40) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:166) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:113) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:58) > at > org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$3(HierarchicalTestExecutor.java:112) > at > org.junit.platform.engine.support.hierarchical.SingleTestExecutor.executeSafely(SingleTestExecutor.java:66) > at > org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.executeRecursively(HierarchicalTestExecutor.java:108) > at > org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.execute(HierarchicalTestExecutor.java:79) > at > org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$2(HierarchicalTestExecutor.java:120) > at > java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184) > at > java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175) > at java.util.Iterator.forEachRemaining(Iterator.java:116) > at > java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801) > at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) > at > java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) > at > java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151) > at > java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174) > at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) > at > java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418) > at > org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$3(HierarchicalTestExecutor.java:120) > at > org.junit.platform.engine.support.hierarchical.SingleTestExecutor.executeSafely(SingleTestExecutor.java:66) > at > org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.executeRecursively(HierarchicalTestExecutor.java:108) > at > org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.execute(HierarchicalTestExecutor.java:79) > at > org.junit.platform.engine.support.hierarchical.H
[jira] [Comment Edited] (VELOCITY-896) Regression in the handling of String literal ending with a sharp sign
[ https://issues.apache.org/jira/browse/VELOCITY-896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16732170#comment-16732170 ] Thomas Mortagne edited comment on VELOCITY-896 at 1/2/19 3:52 PM: -- [~claude] any idea when 2.1 release is planned ? Anything I can do to help ? was (Author: tmortagne): [~claude] any idea when 2.1 release is planned ? > Regression in the handling of String literal ending with a sharp sign > - > > Key: VELOCITY-896 > URL: https://issues.apache.org/jira/browse/VELOCITY-896 > Project: Velocity > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Thomas Mortagne >Assignee: Claude Brisson >Priority: Blocker > Fix For: 2.1 > > > The following produce a ParseErrorException after upgrading to Velocity 2: > {code} > #set($var = "#") > {code} > or > {code} > #set($var = "toto#") > {code} > {noformat} > org.xwiki.velocity.XWikiVelocityException: Failed to evaluate content with id > [mytemplate] > at > org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:279) > at > org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:244) > at > org.xwiki.velocity.internal.DefaultVelocityEngineTest.assertEvaluate(DefaultVelocityEngineTest.java:92) > at > org.xwiki.velocity.internal.DefaultVelocityEngineTest.assertEvaluate(DefaultVelocityEngineTest.java:85) > at > org.xwiki.velocity.internal.DefaultVelocityEngineTest.testMisc(DefaultVelocityEngineTest.java:287) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:436) > at > org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:115) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$6(TestMethodTestDescriptor.java:170) > at > org.junit.jupiter.engine.execution.ThrowableCollector.execute(ThrowableCollector.java:40) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:166) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:113) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:58) > at > org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$3(HierarchicalTestExecutor.java:112) > at > org.junit.platform.engine.support.hierarchical.SingleTestExecutor.executeSafely(SingleTestExecutor.java:66) > at > org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.executeRecursively(HierarchicalTestExecutor.java:108) > at > org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.execute(HierarchicalTestExecutor.java:79) > at > org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$2(HierarchicalTestExecutor.java:120) > at > java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184) > at > java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175) > at java.util.Iterator.forEachRemaining(Iterator.java:116) > at > java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801) > at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) > at > java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) > at > java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151) > at > java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174) > at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) > at > java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418) > at > org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$3(HierarchicalTestExecutor.java:120) > at > org.junit.platform.engine.support.hierarchical.SingleTestExecutor.executeSafely(SingleTestExecutor.java:66) > at > org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.executeRecursively(HierarchicalTestExecutor.java:108) > at > org.junit.platform.engine.support.hier
[jira] [Commented] (VELOCITY-918) Using commons-collection version 3.2.1 which having vulnerabilities
[ https://issues.apache.org/jira/browse/VELOCITY-918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16885909#comment-16885909 ] Thomas Mortagne commented on VELOCITY-918: -- The artifact id changed, see http://velocity.apache.org/engine/2.1/upgrading.html#upgrading-from-velocity-17-to-velocity-20. > Using commons-collection version 3.2.1 which having vulnerabilities > --- > > Key: VELOCITY-918 > URL: https://issues.apache.org/jira/browse/VELOCITY-918 > Project: Velocity > Issue Type: Bug >Reporter: Shubhankar Singh >Priority: Major > Attachments: vulnerability.PNG > > -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-904) Add a flag for better backward compatibility with null macro arguments
[ https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16987724#comment-16987724 ] Thomas Mortagne commented on VELOCITY-904: -- Looks like there is still differences with 1.7 when the passed variable is not null. {code} #macro(testmacro $parameter) #set($parameter = $NULL) $parameter #end #set($return = 'value') #testmacro($return) {code} 1.7: $return 2.2RC1: $parameter We have some code which expect the 1.7 behaviour so while it's easy to workaround (set it to null before calling testmacro) it's not very convenient and not easy to track down all places to fix for 2.2 plus we don't control all the scripts used with XWiki as a development platform anyway so it can be a big breakage for some users. > Add a flag for better backward compatibility with null macro arguments > -- > > Key: VELOCITY-904 > URL: https://issues.apache.org/jira/browse/VELOCITY-904 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.0 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Minor > Fix For: 2.1 > > > See [this > comment|https://issues.apache.org/jira/browse/VELOCITY-542?focusedCommentId=16621819&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16621819] > : > {code} > #macro(testmacro $parameter) > $parameter > #end > #testmacro($return) > {code} > bq. which used to print "$return" (when $return is null or undefined) and we > now get "$parameter". > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-904) Add a flag for better backward compatibility with null macro arguments
[ https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16989054#comment-16989054 ] Thomas Mortagne commented on VELOCITY-904: -- Thanks a lot [~cbrisson] ! > Add a flag for better backward compatibility with null macro arguments > -- > > Key: VELOCITY-904 > URL: https://issues.apache.org/jira/browse/VELOCITY-904 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.0 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Minor > Fix For: 2.2 > > > See [this > comment|https://issues.apache.org/jira/browse/VELOCITY-542?focusedCommentId=16621819&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16621819] > : > {code} > #macro(testmacro $parameter) > $parameter > #end > #testmacro($return) > {code} > bq. which used to print "$return" (when $return is null or undefined) and we > now get "$parameter". > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-904) Add a flag for better backward compatibility with null macro arguments
[ https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16991799#comment-16991799 ] Thomas Mortagne commented on VELOCITY-904: -- I just built velocity-engine SNAPSHOT and it works great indeed. Anything I can help to have the 2.2 release ASAP ? ;) > Add a flag for better backward compatibility with null macro arguments > -- > > Key: VELOCITY-904 > URL: https://issues.apache.org/jira/browse/VELOCITY-904 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.0 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Minor > Fix For: 2.2 > > > See [this > comment|https://issues.apache.org/jira/browse/VELOCITY-542?focusedCommentId=16621819&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16621819] > : > {code} > #macro(testmacro $parameter) > $parameter > #end > #testmacro($return) > {code} > bq. which used to print "$return" (when $return is null or undefined) and we > now get "$parameter". > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-904) Add a flag for better backward compatibility with null macro arguments
[ https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16991799#comment-16991799 ] Thomas Mortagne edited comment on VELOCITY-904 at 12/9/19 5:45 PM: --- I just built velocity-engine SNAPSHOT and it works great indeed. Anything I can help with to have the 2.2 release ASAP ? ;) was (Author: tmortagne): I just built velocity-engine SNAPSHOT and it works great indeed. Anything I can help to have the 2.2 release ASAP ? ;) > Add a flag for better backward compatibility with null macro arguments > -- > > Key: VELOCITY-904 > URL: https://issues.apache.org/jira/browse/VELOCITY-904 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.0 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Minor > Fix For: 2.2 > > > See [this > comment|https://issues.apache.org/jira/browse/VELOCITY-542?focusedCommentId=16621819&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16621819] > : > {code} > #macro(testmacro $parameter) > $parameter > #end > #testmacro($return) > {code} > bq. which used to print "$return" (when $return is null or undefined) and we > now get "$parameter". > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Created] (VELOCITY-923) New syntax error when || follow a Velocity expression
Thomas Mortagne created VELOCITY-923: Summary: New syntax error when || follow a Velocity expression Key: VELOCITY-923 URL: https://issues.apache.org/jira/browse/VELOCITY-923 Project: Velocity Issue Type: Bug Affects Versions: 2.2 Reporter: Thomas Mortagne The following fail in Velocity 2.2-SNAPSHOT: {code} $var|| {code} but works fine in 1.7. The workarounds is to put the expression inside {} (as in ${var}) Since || is a wiki syntax in our case it's not rare to see table cells containing a Velocity variable (without any {} protection since it was working well in 1.7). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-923) New syntax error when || follow a Velocity expression
[ https://issues.apache.org/jira/browse/VELOCITY-923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mortagne updated VELOCITY-923: - Labels: regresion (was: ) > New syntax error when || follow a Velocity expression > - > > Key: VELOCITY-923 > URL: https://issues.apache.org/jira/browse/VELOCITY-923 > Project: Velocity > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Thomas Mortagne >Priority: Blocker > Labels: regresion > > The following fail in Velocity 2.2-SNAPSHOT: > {code} > $var|| > {code} > but works fine in 1.7. > The workarounds is to put the expression inside {} (as in ${var}) > Since || is a wiki syntax in our case it's not rare to see table cells > containing a Velocity variable (without any {} protection since it was > working well in 1.7). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-923) New syntax error when || follow a Velocity expression
[ https://issues.apache.org/jira/browse/VELOCITY-923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mortagne updated VELOCITY-923: - Labels: regression (was: regresion) > New syntax error when || follow a Velocity expression > - > > Key: VELOCITY-923 > URL: https://issues.apache.org/jira/browse/VELOCITY-923 > Project: Velocity > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Thomas Mortagne >Priority: Blocker > Labels: regression > > The following fail in Velocity 2.2-SNAPSHOT: > {code} > $var|| > {code} > but works fine in 1.7. > The workarounds is to put the expression inside {} (as in ${var}) > Since || is a wiki syntax in our case it's not rare to see table cells > containing a Velocity variable (without any {} protection since it was > working well in 1.7). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-923) New syntax error when || follow a Velocity expression
[ https://issues.apache.org/jira/browse/VELOCITY-923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mortagne updated VELOCITY-923: - Description: The following fail in Velocity 2.2-SNAPSHOT: {code} $var|| {code} but works fine in 1.7. The workarounds is to put the expression inside {} (as in ${var}) Since || is a wiki syntax in our case it's not rare to see table cells or a link label containing a Velocity variable (without any {} protection since it was working well in 1.7). was: The following fail in Velocity 2.2-SNAPSHOT: {code} $var|| {code} but works fine in 1.7. The workarounds is to put the expression inside {} (as in ${var}) Since || is a wiki syntax in our case it's not rare to see table cells containing a Velocity variable (without any {} protection since it was working well in 1.7). > New syntax error when || follow a Velocity expression > - > > Key: VELOCITY-923 > URL: https://issues.apache.org/jira/browse/VELOCITY-923 > Project: Velocity > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Thomas Mortagne >Priority: Blocker > Labels: regression > > The following fail in Velocity 2.2-SNAPSHOT: > {code} > $var|| > {code} > but works fine in 1.7. > The workarounds is to put the expression inside {} (as in ${var}) > Since || is a wiki syntax in our case it's not rare to see table cells or a > link label containing a Velocity variable (without any {} protection since it > was working well in 1.7). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-923) New syntax error when || follow a Velocity expression
[ https://issues.apache.org/jira/browse/VELOCITY-923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mortagne updated VELOCITY-923: - Description: The following fail in Velocity 2.2-SNAPSHOT: {code} $var|| {code} but works fine in 1.7. The workarounds is to put the expression inside {} (as in ${var}) Since || is a wiki syntax in our case it's not rare to see table cells or a link reference containing a Velocity variable (without any {} protection since it was working well in 1.7). was: The following fail in Velocity 2.2-SNAPSHOT: {code} $var|| {code} but works fine in 1.7. The workarounds is to put the expression inside {} (as in ${var}) Since || is a wiki syntax in our case it's not rare to see table cells or a link label containing a Velocity variable (without any {} protection since it was working well in 1.7). > New syntax error when || follow a Velocity expression > - > > Key: VELOCITY-923 > URL: https://issues.apache.org/jira/browse/VELOCITY-923 > Project: Velocity > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Thomas Mortagne >Priority: Blocker > Labels: regression > > The following fail in Velocity 2.2-SNAPSHOT: > {code} > $var|| > {code} > but works fine in 1.7. > The workarounds is to put the expression inside {} (as in ${var}) > Since || is a wiki syntax in our case it's not rare to see table cells or a > link reference containing a Velocity variable (without any {} protection > since it was working well in 1.7). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-923) Parser regression when || follow a Velocity expression
[ https://issues.apache.org/jira/browse/VELOCITY-923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mortagne updated VELOCITY-923: - Summary: Parser regression when || follow a Velocity expression (was: New syntax error when || follow a Velocity expression) > Parser regression when || follow a Velocity expression > -- > > Key: VELOCITY-923 > URL: https://issues.apache.org/jira/browse/VELOCITY-923 > Project: Velocity > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Thomas Mortagne >Priority: Blocker > Labels: regression > > The following fail in Velocity 2.2-SNAPSHOT: > {code} > $var|| > {code} > but works fine in 1.7. > The workarounds is to put the expression inside {} (as in ${var}) > Since || is a wiki syntax in our case it's not rare to see table cells or a > link reference containing a Velocity variable (without any {} protection > since it was working well in 1.7). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-904) Add a flag for better backward compatibility with null macro arguments
[ https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16994810#comment-16994810 ] Thomas Mortagne commented on VELOCITY-904: -- Actually I found another issue related to this retro compatibility option: {code} {{velocity}} #macro(macro1 $return) 1: $return #macro2($param2) 1: $return #end #macro(macro2 $return) 2: $return #end #macro1($param) {{/velocity}} {code} 1.7: {noformat} 1: $param 2: $param2 1: $param {noformat} 2.2-SNAPSHOT: {noformat} 1: $param 2: $param2 1: $return {noformat} The sub macro call "break" the parameter. > Add a flag for better backward compatibility with null macro arguments > -- > > Key: VELOCITY-904 > URL: https://issues.apache.org/jira/browse/VELOCITY-904 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.0 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Minor > Fix For: 2.2 > > > See [this > comment|https://issues.apache.org/jira/browse/VELOCITY-542?focusedCommentId=16621819&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16621819] > : > {code} > #macro(testmacro $parameter) > $parameter > #end > #testmacro($return) > {code} > bq. which used to print "$return" (when $return is null or undefined) and we > now get "$parameter". > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-904) Add a flag for better backward compatibility with null macro arguments
[ https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16995447#comment-16995447 ] Thomas Mortagne commented on VELOCITY-904: -- bq. I can't also help thinking that your use of null macro arguments is somewhat a corner case of macro usages which is very specific to xwiki, but at least it makes xwiki a good regression candidate. Yeah I'm not very proud of that either but I have to work with history unfortunately... > Add a flag for better backward compatibility with null macro arguments > -- > > Key: VELOCITY-904 > URL: https://issues.apache.org/jira/browse/VELOCITY-904 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.0 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Minor > Fix For: 2.2 > > > See [this > comment|https://issues.apache.org/jira/browse/VELOCITY-542?focusedCommentId=16621819&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16621819] > : > {code} > #macro(testmacro $parameter) > $parameter > #end > #testmacro($return) > {code} > bq. which used to print "$return" (when $return is null or undefined) and we > now get "$parameter". > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-923) Parser regression when || follow a Velocity expression
[ https://issues.apache.org/jira/browse/VELOCITY-923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16995448#comment-16995448 ] Thomas Mortagne commented on VELOCITY-923: -- As usual thanks a lot [~cbrisson] for this quick fix ! > Parser regression when || follow a Velocity expression > -- > > Key: VELOCITY-923 > URL: https://issues.apache.org/jira/browse/VELOCITY-923 > Project: Velocity > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Thomas Mortagne >Assignee: Claude Brisson >Priority: Blocker > Labels: regression > Fix For: 2.2 > > > The following fail in Velocity 2.2-SNAPSHOT: > {code} > $var|| > {code} > but works fine in 1.7. > The workarounds is to put the expression inside {} (as in ${var}) > Since || is a wiki syntax in our case it's not rare to see table cells or a > link reference containing a Velocity variable (without any {} protection > since it was working well in 1.7). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-904) Add a flag for better backward compatibility with null macro arguments
[ https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16995447#comment-16995447 ] Thomas Mortagne edited comment on VELOCITY-904 at 12/13/19 8:12 AM: bq. I can't also help thinking that your use of null macro arguments is somewhat a corner case of macro usages which is very specific to xwiki, but at least it makes xwiki a good regression candidate. Yeah I'm not very proud of that either but I have to work with history unfortunately... Currently trying to think about a cleaner way to deal with this macro return need which involve a lot less hacking that people would use and which would be less impacted by Velocity internals. was (Author: tmortagne): bq. I can't also help thinking that your use of null macro arguments is somewhat a corner case of macro usages which is very specific to xwiki, but at least it makes xwiki a good regression candidate. Yeah I'm not very proud of that either but I have to work with history unfortunately... > Add a flag for better backward compatibility with null macro arguments > -- > > Key: VELOCITY-904 > URL: https://issues.apache.org/jira/browse/VELOCITY-904 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.0 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Minor > Fix For: 2.2 > > > See [this > comment|https://issues.apache.org/jira/browse/VELOCITY-542?focusedCommentId=16621819&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16621819] > : > {code} > #macro(testmacro $parameter) > $parameter > #end > #testmacro($return) > {code} > bq. which used to print "$return" (when $return is null or undefined) and we > now get "$parameter". > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-904) Add a flag for better backward compatibility with null macro arguments
[ https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16995447#comment-16995447 ] Thomas Mortagne edited comment on VELOCITY-904 at 12/13/19 8:23 AM: bq. I can't also help thinking that your use of null macro arguments is somewhat a corner case of macro usages which is very specific to xwiki, but at least it makes xwiki a good regression candidate. Yeah I'm not very proud of that either but I have to work with history unfortunately... Currently trying to think about a cleaner way to deal with this macro return need which involve a lot less hacking that people would use and which would be less impacted by Velocity internals. bq. To answer your question about what you can do to help speed up the release process, well, all the tests and regressions that you do discover are certainly helpful to improve the quality of the release, especially about backward compatibility, and we thank you for them, but I'm not sure they're making the release process faster... I must say I was not expecting to find more issues when I asked the question but yes not exactly the best to speed up the release :) was (Author: tmortagne): bq. I can't also help thinking that your use of null macro arguments is somewhat a corner case of macro usages which is very specific to xwiki, but at least it makes xwiki a good regression candidate. Yeah I'm not very proud of that either but I have to work with history unfortunately... Currently trying to think about a cleaner way to deal with this macro return need which involve a lot less hacking that people would use and which would be less impacted by Velocity internals. > Add a flag for better backward compatibility with null macro arguments > -- > > Key: VELOCITY-904 > URL: https://issues.apache.org/jira/browse/VELOCITY-904 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.0 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Minor > Fix For: 2.2 > > > See [this > comment|https://issues.apache.org/jira/browse/VELOCITY-542?focusedCommentId=16621819&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16621819] > : > {code} > #macro(testmacro $parameter) > $parameter > #end > #testmacro($return) > {code} > bq. which used to print "$return" (when $return is null or undefined) and we > now get "$parameter". > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-904) Add a flag for better backward compatibility with null macro arguments
[ https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16995684#comment-16995684 ] Thomas Mortagne commented on VELOCITY-904: -- OK thanks [~cbrisson] I will take that into account. > Add a flag for better backward compatibility with null macro arguments > -- > > Key: VELOCITY-904 > URL: https://issues.apache.org/jira/browse/VELOCITY-904 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.0 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Minor > Fix For: 2.2 > > > See [this > comment|https://issues.apache.org/jira/browse/VELOCITY-542?focusedCommentId=16621819&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16621819] > : > {code} > #macro(testmacro $parameter) > $parameter > #end > #testmacro($return) > {code} > bq. which used to print "$return" (when $return is null or undefined) and we > now get "$parameter". > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Created] (VELOCITY-924) Bad cache handling for java.lang.Class methods
Thomas Mortagne created VELOCITY-924: Summary: Bad cache handling for java.lang.Class methods Key: VELOCITY-924 URL: https://issues.apache.org/jira/browse/VELOCITY-924 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 2.2 Reporter: Thomas Mortagne Requirement: A binding $var containing an object which class (org.xwiki.MyClass) implementing a {{String getName()}} method. The following code: {code} $var.class.getName() $var.getName() {code} fail with: {noformat} Caused by: org.apache.velocity.exception.MethodInvocationException: Invocation of method 'getName' in class org.xwiki.MyClass threw exception java.lang.IllegalArgumentException: object is not an instance of declaring class at mytemplaye[line 1, column 26] at org.apache.velocity.runtime.parser.node.ASTMethod.handleInvocationException(ASTMethod.java:306) at org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:239) at org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:369) at org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:490) at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:423) at org.apache.velocity.Template.merge(Template.java:358) at org.apache.velocity.Template.merge(Template.java:262) at org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:271) ... 69 more Caused by: java.lang.IllegalArgumentException: object is not an instance of declaring class at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:565) at org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:548) at org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:219) ... 75 more {noformat} The reason is that ClassUtils.getMethod cache does not make any difference between an instance of Class and and instance of org.xwiki.MyClass so when ASTMethod#execute ask for the second getName() it end up with Class#getName() instead of MyClass#getName(). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-924) Bad cache handling for java.lang.Class methods
[ https://issues.apache.org/jira/browse/VELOCITY-924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mortagne updated VELOCITY-924: - Description: Requirement: A binding $var containing an object which class (org.xwiki.MyClass) implementing a {{String getName()}} method. The following code: {code} $var.class.getName() $var.getName() {code} fail with: {noformat} Caused by: org.apache.velocity.exception.MethodInvocationException: Invocation of method 'getName' in class org.xwiki.MyClass threw exception java.lang.IllegalArgumentException: object is not an instance of declaring class at mytemplaye[line 1, column 26] at org.apache.velocity.runtime.parser.node.ASTMethod.handleInvocationException(ASTMethod.java:306) at org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:239) at org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:369) at org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:490) at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:423) at org.apache.velocity.Template.merge(Template.java:358) at org.apache.velocity.Template.merge(Template.java:262) at org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:271) ... 69 more Caused by: java.lang.IllegalArgumentException: object is not an instance of declaring class at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:565) at org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:548) at org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:219) ... 75 more {noformat} The reason is that ClassUtils.getMethod cache does not make any difference between an instance of Class and and instance of org.xwiki.MyClass so when ASTMethod#execute ask for the second getName() it end up with Class#getName() instead of MyClass#getName(). Was working fine in 1.7. was: Requirement: A binding $var containing an object which class (org.xwiki.MyClass) implementing a {{String getName()}} method. The following code: {code} $var.class.getName() $var.getName() {code} fail with: {noformat} Caused by: org.apache.velocity.exception.MethodInvocationException: Invocation of method 'getName' in class org.xwiki.MyClass threw exception java.lang.IllegalArgumentException: object is not an instance of declaring class at mytemplaye[line 1, column 26] at org.apache.velocity.runtime.parser.node.ASTMethod.handleInvocationException(ASTMethod.java:306) at org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:239) at org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:369) at org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:490) at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:423) at org.apache.velocity.Template.merge(Template.java:358) at org.apache.velocity.Template.merge(Template.java:262) at org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:271) ... 69 more Caused by: java.lang.IllegalArgumentException: object is not an instance of declaring class at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:565) at org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:548) at org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:219) ... 75 more {noformat} The reason is that ClassUtils.getMethod cache does not make any difference between an instance of Class and and instance of org.xwiki.MyClass so when ASTMethod#execute ask for the second getName() it end up with Class#getName() instead of MyClass#getName(). > Bad cache handling for java.lang.Class methods > -- > > Key: VELOCITY-924 > URL: https://issues.apache.org/jira/browse/VELOCITY-924 > Project: Velocity > Issue Type: Bug >
[jira] [Updated] (VELOCITY-924) Bad cache handling for java.lang.Class methods
[ https://issues.apache.org/jira/browse/VELOCITY-924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mortagne updated VELOCITY-924: - Labels: regression (was: ) > Bad cache handling for java.lang.Class methods > -- > > Key: VELOCITY-924 > URL: https://issues.apache.org/jira/browse/VELOCITY-924 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.2 >Reporter: Thomas Mortagne >Priority: Blocker > Labels: regression > > Requirement: > A binding $var containing an object which class (org.xwiki.MyClass) > implementing a {{String getName()}} method. > The following code: > {code} > $var.class.getName() > $var.getName() > {code} > fail with: > {noformat} > Caused by: org.apache.velocity.exception.MethodInvocationException: > Invocation of method 'getName' in class org.xwiki.MyClass threw exception > java.lang.IllegalArgumentException: object is not an instance of declaring > class at mytemplaye[line 1, column 26] > at > org.apache.velocity.runtime.parser.node.ASTMethod.handleInvocationException(ASTMethod.java:306) > at > org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:239) > at > org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:369) > at > org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:490) > at > org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:423) > at org.apache.velocity.Template.merge(Template.java:358) > at org.apache.velocity.Template.merge(Template.java:262) > at > org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:271) > ... 69 more > Caused by: java.lang.IllegalArgumentException: object is not an instance of > declaring class > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:565) > at > org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:548) > at > org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:219) > ... 75 more > {noformat} > The reason is that ClassUtils.getMethod cache does not make any difference > between an instance of Class and and instance of > org.xwiki.MyClass so when ASTMethod#execute ask for the second getName() it > end up with Class#getName() instead of MyClass#getName(). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-924) Bad cache handling for java.lang.Class methods
[ https://issues.apache.org/jira/browse/VELOCITY-924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17008402#comment-17008402 ] Thomas Mortagne commented on VELOCITY-924: -- OK maybe it needs some specific configuration then: * configuration: https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/internal/DefaultVelocityConfiguration.java#L103 * test case on XWiki side: https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/test/java/org/xwiki/velocity/internal/DefaultVelocityEngineTest.java#L399 * failing test https://ci.xwiki.org/job/XWiki/job/xwiki-commons/job/master/1025/testReport/junit/org.xwiki.velocity.internal/DefaultVelocityEngineTest/Commons_Builds___main___Build_for_Main___testClassMethods/ > Bad cache handling for java.lang.Class methods > -- > > Key: VELOCITY-924 > URL: https://issues.apache.org/jira/browse/VELOCITY-924 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.2 >Reporter: Thomas Mortagne >Priority: Blocker > Labels: regression > > Requirement: > A binding $var containing an object which class (org.xwiki.MyClass) > implementing a {{String getName()}} method. > The following code: > {code} > $var.class.getName() > $var.getName() > {code} > fail with: > {noformat} > Caused by: org.apache.velocity.exception.MethodInvocationException: > Invocation of method 'getName' in class org.xwiki.MyClass threw exception > java.lang.IllegalArgumentException: object is not an instance of declaring > class at mytemplaye[line 1, column 26] > at > org.apache.velocity.runtime.parser.node.ASTMethod.handleInvocationException(ASTMethod.java:306) > at > org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:239) > at > org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:369) > at > org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:490) > at > org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:423) > at org.apache.velocity.Template.merge(Template.java:358) > at org.apache.velocity.Template.merge(Template.java:262) > at > org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:271) > ... 69 more > Caused by: java.lang.IllegalArgumentException: object is not an instance of > declaring class > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:565) > at > org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:548) > at > org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:219) > ... 75 more > {noformat} > The reason is that ClassUtils.getMethod cache does not make any difference > between an instance of Class and and instance of > org.xwiki.MyClass so when ASTMethod#execute ask for the second getName() it > end up with Class#getName() instead of MyClass#getName(). > Was working fine in 1.7. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-924) Bad cache handling for java.lang.Class methods
[ https://issues.apache.org/jira/browse/VELOCITY-924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17008402#comment-17008402 ] Thomas Mortagne edited comment on VELOCITY-924 at 1/5/20 7:25 PM: -- OK maybe it needs some specific configuration then: * configuration: https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/internal/DefaultVelocityConfiguration.java#L103 * test case on XWiki side: https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/test/java/org/xwiki/velocity/internal/DefaultVelocityEngineTest.java#L399 * failling test result https://ci.xwiki.org/job/XWiki/job/xwiki-commons/job/master/1025/testReport/junit/org.xwiki.velocity.internal/DefaultVelocityEngineTest/Commons_Builds___main___Build_for_Main___testClassMethods/ was (Author: tmortagne): OK maybe it needs some specific configuration then: * configuration: https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/internal/DefaultVelocityConfiguration.java#L103 * test case on XWiki side: https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/test/java/org/xwiki/velocity/internal/DefaultVelocityEngineTest.java#L399 * failing test https://ci.xwiki.org/job/XWiki/job/xwiki-commons/job/master/1025/testReport/junit/org.xwiki.velocity.internal/DefaultVelocityEngineTest/Commons_Builds___main___Build_for_Main___testClassMethods/ > Bad cache handling for java.lang.Class methods > -- > > Key: VELOCITY-924 > URL: https://issues.apache.org/jira/browse/VELOCITY-924 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.2 >Reporter: Thomas Mortagne >Priority: Blocker > Labels: regression > > Requirement: > A binding $var containing an object which class (org.xwiki.MyClass) > implementing a {{String getName()}} method. > The following code: > {code} > $var.class.getName() > $var.getName() > {code} > fail with: > {noformat} > Caused by: org.apache.velocity.exception.MethodInvocationException: > Invocation of method 'getName' in class org.xwiki.MyClass threw exception > java.lang.IllegalArgumentException: object is not an instance of declaring > class at mytemplaye[line 1, column 26] > at > org.apache.velocity.runtime.parser.node.ASTMethod.handleInvocationException(ASTMethod.java:306) > at > org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:239) > at > org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:369) > at > org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:490) > at > org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:423) > at org.apache.velocity.Template.merge(Template.java:358) > at org.apache.velocity.Template.merge(Template.java:262) > at > org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:271) > ... 69 more > Caused by: java.lang.IllegalArgumentException: object is not an instance of > declaring class > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:565) > at > org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:548) > at > org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:219) > ... 75 more > {noformat} > The reason is that ClassUtils.getMethod cache does not make any difference > between an instance of Class and and instance of > org.xwiki.MyClass so when ASTMethod#execute ask for the second getName() it > end up with Class#getName() instead of MyClass#getName(). > Was working fine in 1.7. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-924) Bad cache handling for java.lang.Class methods
[ https://issues.apache.org/jira/browse/VELOCITY-924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17011805#comment-17011805 ] Thomas Mortagne commented on VELOCITY-924: -- I just built a SNAPSHOT of Velocity trunk and while I don't get any error anymore the new behavior is that it find no method at all instead of the wrong one. > Bad cache handling for java.lang.Class methods > -- > > Key: VELOCITY-924 > URL: https://issues.apache.org/jira/browse/VELOCITY-924 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.2 >Reporter: Thomas Mortagne >Assignee: Claude Brisson >Priority: Blocker > Labels: regression > Fix For: 2.2 > > > Requirement: > A binding $var containing an object which class (org.xwiki.MyClass) > implementing a {{String getName()}} method. > The following code: > {code} > $var.class.getName() > $var.getName() > {code} > fail with: > {noformat} > Caused by: org.apache.velocity.exception.MethodInvocationException: > Invocation of method 'getName' in class org.xwiki.MyClass threw exception > java.lang.IllegalArgumentException: object is not an instance of declaring > class at mytemplaye[line 1, column 26] > at > org.apache.velocity.runtime.parser.node.ASTMethod.handleInvocationException(ASTMethod.java:306) > at > org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:239) > at > org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:369) > at > org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:490) > at > org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:423) > at org.apache.velocity.Template.merge(Template.java:358) > at org.apache.velocity.Template.merge(Template.java:262) > at > org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:271) > ... 69 more > Caused by: java.lang.IllegalArgumentException: object is not an instance of > declaring class > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:565) > at > org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:548) > at > org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:219) > ... 75 more > {noformat} > The reason is that ClassUtils.getMethod cache does not make any difference > between an instance of Class and and instance of > org.xwiki.MyClass so when ASTMethod#execute ask for the second getName() it > end up with Class#getName() instead of MyClass#getName(). > Was working fine in 1.7. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-924) Bad cache handling for java.lang.Class methods
[ https://issues.apache.org/jira/browse/VELOCITY-924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17011805#comment-17011805 ] Thomas Mortagne edited comment on VELOCITY-924 at 1/9/20 1:30 PM: -- I just built a SNAPSHOT of Velocity trunk and while I don't get any error anymore the new behavior is that it find no method at all instead of the wrong one so still not great. For example in my use case it should call TestClass#getName() but it does not find this method. was (Author: tmortagne): I just built a SNAPSHOT of Velocity trunk and while I don't get any error anymore the new behavior is that it find no method at all instead of the wrong one. > Bad cache handling for java.lang.Class methods > -- > > Key: VELOCITY-924 > URL: https://issues.apache.org/jira/browse/VELOCITY-924 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.2 >Reporter: Thomas Mortagne >Assignee: Claude Brisson >Priority: Blocker > Labels: regression > Fix For: 2.2 > > > Requirement: > A binding $var containing an object which class (org.xwiki.MyClass) > implementing a {{String getName()}} method. > The following code: > {code} > $var.class.getName() > $var.getName() > {code} > fail with: > {noformat} > Caused by: org.apache.velocity.exception.MethodInvocationException: > Invocation of method 'getName' in class org.xwiki.MyClass threw exception > java.lang.IllegalArgumentException: object is not an instance of declaring > class at mytemplaye[line 1, column 26] > at > org.apache.velocity.runtime.parser.node.ASTMethod.handleInvocationException(ASTMethod.java:306) > at > org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:239) > at > org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:369) > at > org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:490) > at > org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:423) > at org.apache.velocity.Template.merge(Template.java:358) > at org.apache.velocity.Template.merge(Template.java:262) > at > org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:271) > ... 69 more > Caused by: java.lang.IllegalArgumentException: object is not an instance of > declaring class > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:565) > at > org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:548) > at > org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:219) > ... 75 more > {noformat} > The reason is that ClassUtils.getMethod cache does not make any difference > between an instance of Class and and instance of > org.xwiki.MyClass so when ASTMethod#execute ask for the second getName() it > end up with Class#getName() instead of MyClass#getName(). > Was working fine in 1.7. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-924) Bad cache handling for java.lang.Class methods
[ https://issues.apache.org/jira/browse/VELOCITY-924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17011815#comment-17011815 ] Thomas Mortagne commented on VELOCITY-924: -- Actually this behavior might be expected, not sure. It works well when the class is public. > Bad cache handling for java.lang.Class methods > -- > > Key: VELOCITY-924 > URL: https://issues.apache.org/jira/browse/VELOCITY-924 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.2 >Reporter: Thomas Mortagne >Assignee: Claude Brisson >Priority: Blocker > Labels: regression > Fix For: 2.2 > > > Requirement: > A binding $var containing an object which class (org.xwiki.MyClass) > implementing a {{String getName()}} method. > The following code: > {code} > $var.class.getName() > $var.getName() > {code} > fail with: > {noformat} > Caused by: org.apache.velocity.exception.MethodInvocationException: > Invocation of method 'getName' in class org.xwiki.MyClass threw exception > java.lang.IllegalArgumentException: object is not an instance of declaring > class at mytemplaye[line 1, column 26] > at > org.apache.velocity.runtime.parser.node.ASTMethod.handleInvocationException(ASTMethod.java:306) > at > org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:239) > at > org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:369) > at > org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:490) > at > org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:423) > at org.apache.velocity.Template.merge(Template.java:358) > at org.apache.velocity.Template.merge(Template.java:262) > at > org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:271) > ... 69 more > Caused by: java.lang.IllegalArgumentException: object is not an instance of > declaring class > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:565) > at > org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:548) > at > org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:219) > ... 75 more > {noformat} > The reason is that ClassUtils.getMethod cache does not make any difference > between an instance of Class and and instance of > org.xwiki.MyClass so when ASTMethod#execute ask for the second getName() it > end up with Class#getName() instead of MyClass#getName(). > Was working fine in 1.7. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-924) Bad cache handling for java.lang.Class methods
[ https://issues.apache.org/jira/browse/VELOCITY-924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17011815#comment-17011815 ] Thomas Mortagne edited comment on VELOCITY-924 at 1/9/20 1:34 PM: -- Actually this behavior might be expected. It works well when the class itself is public. was (Author: tmortagne): Actually this behavior might be expected, not sure. It works well when the class is public. > Bad cache handling for java.lang.Class methods > -- > > Key: VELOCITY-924 > URL: https://issues.apache.org/jira/browse/VELOCITY-924 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.2 >Reporter: Thomas Mortagne >Assignee: Claude Brisson >Priority: Blocker > Labels: regression > Fix For: 2.2 > > > Requirement: > A binding $var containing an object which class (org.xwiki.MyClass) > implementing a {{String getName()}} method. > The following code: > {code} > $var.class.getName() > $var.getName() > {code} > fail with: > {noformat} > Caused by: org.apache.velocity.exception.MethodInvocationException: > Invocation of method 'getName' in class org.xwiki.MyClass threw exception > java.lang.IllegalArgumentException: object is not an instance of declaring > class at mytemplaye[line 1, column 26] > at > org.apache.velocity.runtime.parser.node.ASTMethod.handleInvocationException(ASTMethod.java:306) > at > org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:239) > at > org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:369) > at > org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:490) > at > org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:423) > at org.apache.velocity.Template.merge(Template.java:358) > at org.apache.velocity.Template.merge(Template.java:262) > at > org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:271) > ... 69 more > Caused by: java.lang.IllegalArgumentException: object is not an instance of > declaring class > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:565) > at > org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:548) > at > org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:219) > ... 75 more > {noformat} > The reason is that ClassUtils.getMethod cache does not make any difference > between an instance of Class and and instance of > org.xwiki.MyClass so when ASTMethod#execute ask for the second getName() it > end up with Class#getName() instead of MyClass#getName(). > Was working fine in 1.7. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-904) Add a flag for better backward compatibility with null macro arguments
[ https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17019513#comment-17019513 ] Thomas Mortagne commented on VELOCITY-904: -- Just found another related regression: {noformat} #macro (testMacro $test $name) $name #end #testMacro($other, $test.name) {noformat} Velocity 1.7: print the result of $test.name Velocity 2.2: print "$test.name" >From what I understand the first parameter of testMacro is injected in the >context before "$test.name" is interpreted so it breaks it (works fine when >renaming the first parameter into $test2 or if $test is the parameter >receiving the expression). > Add a flag for better backward compatibility with null macro arguments > -- > > Key: VELOCITY-904 > URL: https://issues.apache.org/jira/browse/VELOCITY-904 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.0 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Minor > Fix For: 2.2 > > > See [this > comment|https://issues.apache.org/jira/browse/VELOCITY-542?focusedCommentId=16621819&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16621819] > : > {code} > #macro(testmacro $parameter) > $parameter > #end > #testmacro($return) > {code} > bq. which used to print "$return" (when $return is null or undefined) and we > now get "$parameter". > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-904) Add a flag for better backward compatibility with null macro arguments
[ https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17019550#comment-17019550 ] Thomas Mortagne commented on VELOCITY-904: -- Not sure what you mean. Are you saying this behavior is expected ? > Add a flag for better backward compatibility with null macro arguments > -- > > Key: VELOCITY-904 > URL: https://issues.apache.org/jira/browse/VELOCITY-904 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.0 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Minor > Fix For: 2.2 > > > See [this > comment|https://issues.apache.org/jira/browse/VELOCITY-542?focusedCommentId=16621819&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16621819] > : > {code} > #macro(testmacro $parameter) > $parameter > #end > #testmacro($return) > {code} > bq. which used to print "$return" (when $return is null or undefined) and we > now get "$parameter". > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-904) Add a flag for better backward compatibility with null macro arguments
[ https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17019550#comment-17019550 ] Thomas Mortagne edited comment on VELOCITY-904 at 1/20/20 3:18 PM: --- Not sure what you mean. Are you saying this behavior is expected ? If `$test.name` was evaluated beforehand I don't see how the name of the previous macro parameter could have any impact on it. My use case involves "velocimacro.arguments.preserve_literals", maybe you are talking about the default behavior ? was (Author: tmortagne): Not sure what you mean. Are you saying this behavior is expected ? > Add a flag for better backward compatibility with null macro arguments > -- > > Key: VELOCITY-904 > URL: https://issues.apache.org/jira/browse/VELOCITY-904 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.0 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Minor > Fix For: 2.2 > > > See [this > comment|https://issues.apache.org/jira/browse/VELOCITY-542?focusedCommentId=16621819&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16621819] > : > {code} > #macro(testmacro $parameter) > $parameter > #end > #testmacro($return) > {code} > bq. which used to print "$return" (when $return is null or undefined) and we > now get "$parameter". > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-904) Add a flag for better backward compatibility with null macro arguments
[ https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17019574#comment-17019574 ] Thomas Mortagne commented on VELOCITY-904: -- I don't think we understand each other. In my example $test is defined in the global context, it's an object with a method getName() which return something (let's say "value"). $other is not defined so it's null. The calling code does not and should not care about the names of the macro parameters which actually is my main point here, from its point of view it's just passing values (one of which is the result of $test.name evaluation). The problem here is that the macro breaks the input expression passed as second parameter because it happen to define as first parameter a name that affects this expression so it really looks like `$test.name` is NOT evaluated beforehand. Here a more explicit example: {code} #set($test = $someObjectWithAGetNameMethodReturning_value) #set($other = $someObjectWithAGetNameMethodReturning_something) #macro (testMacro $test $name) $name #end $test.name #testMacro($other, $test.name) {code} The result I get is Velocity 1.7: "value" followed by "value" Velocity 2.2: "value" followed by "something" So it's very clear for me that the first parameter of the macro was set to $other and then the expressed passed as second parameter was interpreted based on this new value instead of the one the calling code was expecting. > Add a flag for better backward compatibility with null macro arguments > -- > > Key: VELOCITY-904 > URL: https://issues.apache.org/jira/browse/VELOCITY-904 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.0 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Minor > Fix For: 2.2 > > > See [this > comment|https://issues.apache.org/jira/browse/VELOCITY-542?focusedCommentId=16621819&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16621819] > : > {code} > #macro(testmacro $parameter) > $parameter > #end > #testmacro($return) > {code} > bq. which used to print "$return" (when $return is null or undefined) and we > now get "$parameter". > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-904) Add a flag for better backward compatibility with null macro arguments
[ https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17019574#comment-17019574 ] Thomas Mortagne edited comment on VELOCITY-904 at 1/20/20 4:10 PM: --- I don't think we understand each other. In my example $test is defined in the global context, it's an object with a method getName() which return something (let's say "value"). $other is not defined so it's null. The calling code does not and should not care about the names of the macro parameters which actually is my main point here, from its point of view it's just passing values (one of which is the result of $test.name evaluation). The problem here is that the macro breaks the input expression passed as second parameter because it happen to define as first parameter a name that affects this expression so it really looks like `$test.name` is NOT evaluated beforehand. Here a more explicit example: {code} #set($test = $someObjectWithAGetNameMethodReturning_value) #set($other = $someObjectWithAGetNameMethodReturning_something) #macro (testMacro $test $name) $name #end $test.name #testMacro($other, $test.name) {code} The result I get is Velocity 1.7: "value" followed by "value" Velocity 2.2: "value" followed by "something" So it's very clear for me that the first parameter of the macro was set to $other and only then the expression passed as second parameter was interpreted based on this new value instead of the one the calling code was expecting. was (Author: tmortagne): I don't think we understand each other. In my example $test is defined in the global context, it's an object with a method getName() which return something (let's say "value"). $other is not defined so it's null. The calling code does not and should not care about the names of the macro parameters which actually is my main point here, from its point of view it's just passing values (one of which is the result of $test.name evaluation). The problem here is that the macro breaks the input expression passed as second parameter because it happen to define as first parameter a name that affects this expression so it really looks like `$test.name` is NOT evaluated beforehand. Here a more explicit example: {code} #set($test = $someObjectWithAGetNameMethodReturning_value) #set($other = $someObjectWithAGetNameMethodReturning_something) #macro (testMacro $test $name) $name #end $test.name #testMacro($other, $test.name) {code} The result I get is Velocity 1.7: "value" followed by "value" Velocity 2.2: "value" followed by "something" So it's very clear for me that the first parameter of the macro was set to $other and then the expressed passed as second parameter was interpreted based on this new value instead of the one the calling code was expecting. > Add a flag for better backward compatibility with null macro arguments > -- > > Key: VELOCITY-904 > URL: https://issues.apache.org/jira/browse/VELOCITY-904 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.0 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Minor > Fix For: 2.2 > > > See [this > comment|https://issues.apache.org/jira/browse/VELOCITY-542?focusedCommentId=16621819&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16621819] > : > {code} > #macro(testmacro $parameter) > $parameter > #end > #testmacro($return) > {code} > bq. which used to print "$return" (when $return is null or undefined) and we > now get "$parameter". > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-904) Add a flag for better backward compatibility with null macro arguments
[ https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17019574#comment-17019574 ] Thomas Mortagne edited comment on VELOCITY-904 at 1/20/20 4:11 PM: --- I don't think we understand each other. In my example $test is defined in the global context, it's an object with a method getName() which return something (let's say "value"). $other is not defined so it's null. The calling code does not and should not care about the names of the macro parameters which is actually is my main point here, from its point of view it's just passing values (one of which is the result of $test.name evaluation). The problem here is that the macro breaks the input expression passed as second parameter because it happen to define as first parameter a name that affects this expression so it really looks like `$test.name` is NOT evaluated beforehand. Here a more explicit example: {code} #set($test = $someObjectWithAGetNameMethodReturning_value) #set($other = $someObjectWithAGetNameMethodReturning_something) #macro (testMacro $test $name) $name #end $test.name #testMacro($other, $test.name) {code} The result I get is Velocity 1.7: "value" followed by "value" Velocity 2.2: "value" followed by "something" So it's very clear for me that the first parameter of the macro was set to $other and only then the expression passed as second parameter was interpreted based on this new value instead of the one the calling code was expecting. was (Author: tmortagne): I don't think we understand each other. In my example $test is defined in the global context, it's an object with a method getName() which return something (let's say "value"). $other is not defined so it's null. The calling code does not and should not care about the names of the macro parameters which actually is my main point here, from its point of view it's just passing values (one of which is the result of $test.name evaluation). The problem here is that the macro breaks the input expression passed as second parameter because it happen to define as first parameter a name that affects this expression so it really looks like `$test.name` is NOT evaluated beforehand. Here a more explicit example: {code} #set($test = $someObjectWithAGetNameMethodReturning_value) #set($other = $someObjectWithAGetNameMethodReturning_something) #macro (testMacro $test $name) $name #end $test.name #testMacro($other, $test.name) {code} The result I get is Velocity 1.7: "value" followed by "value" Velocity 2.2: "value" followed by "something" So it's very clear for me that the first parameter of the macro was set to $other and only then the expression passed as second parameter was interpreted based on this new value instead of the one the calling code was expecting. > Add a flag for better backward compatibility with null macro arguments > -- > > Key: VELOCITY-904 > URL: https://issues.apache.org/jira/browse/VELOCITY-904 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.0 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Minor > Fix For: 2.2 > > > See [this > comment|https://issues.apache.org/jira/browse/VELOCITY-542?focusedCommentId=16621819&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16621819] > : > {code} > #macro(testmacro $parameter) > $parameter > #end > #testmacro($return) > {code} > bq. which used to print "$return" (when $return is null or undefined) and we > now get "$parameter". > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-904) Add a flag for better backward compatibility with null macro arguments
[ https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17019574#comment-17019574 ] Thomas Mortagne edited comment on VELOCITY-904 at 1/20/20 4:13 PM: --- I don't think we understand each other. In my example $test is defined in the global context, it's an object with a method getName() which return something (let's say "value"). $other is not defined so it's null. The calling code does not and should not care about the names of the macro parameters which is actually my main point here, from its point of view it's just passing values (one of which is the result of $test.name evaluation). The problem here is that the macro breaks the input expression passed as second parameter because it happen to define as first parameter a name that affects this expression so it really looks like `$test.name` is NOT evaluated beforehand. Here a more explicit example: {code} #set($test = $someObjectWithAGetNameMethodReturning_value) #set($other = $someObjectWithAGetNameMethodReturning_something) #macro (testMacro $test $name) $name #end $test.name #testMacro($other, $test.name) {code} The result I get is Velocity 1.7: "value" followed by "value" Velocity 2.2: "value" followed by "something" So it's very clear for me that the first parameter of the macro was set to $other and only then the expression passed as second parameter was interpreted based on this new value instead of the one the calling code was expecting. was (Author: tmortagne): I don't think we understand each other. In my example $test is defined in the global context, it's an object with a method getName() which return something (let's say "value"). $other is not defined so it's null. The calling code does not and should not care about the names of the macro parameters which is actually is my main point here, from its point of view it's just passing values (one of which is the result of $test.name evaluation). The problem here is that the macro breaks the input expression passed as second parameter because it happen to define as first parameter a name that affects this expression so it really looks like `$test.name` is NOT evaluated beforehand. Here a more explicit example: {code} #set($test = $someObjectWithAGetNameMethodReturning_value) #set($other = $someObjectWithAGetNameMethodReturning_something) #macro (testMacro $test $name) $name #end $test.name #testMacro($other, $test.name) {code} The result I get is Velocity 1.7: "value" followed by "value" Velocity 2.2: "value" followed by "something" So it's very clear for me that the first parameter of the macro was set to $other and only then the expression passed as second parameter was interpreted based on this new value instead of the one the calling code was expecting. > Add a flag for better backward compatibility with null macro arguments > -- > > Key: VELOCITY-904 > URL: https://issues.apache.org/jira/browse/VELOCITY-904 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.0 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Minor > Fix For: 2.2 > > > See [this > comment|https://issues.apache.org/jira/browse/VELOCITY-542?focusedCommentId=16621819&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16621819] > : > {code} > #macro(testmacro $parameter) > $parameter > #end > #testmacro($return) > {code} > bq. which used to print "$return" (when $return is null or undefined) and we > now get "$parameter". > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-904) Add a flag for better backward compatibility with null macro arguments
[ https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17021215#comment-17021215 ] Thomas Mortagne commented on VELOCITY-904: -- Is it more clear with my last example [~cbrisson] ? > Add a flag for better backward compatibility with null macro arguments > -- > > Key: VELOCITY-904 > URL: https://issues.apache.org/jira/browse/VELOCITY-904 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.0 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Minor > Fix For: 2.2 > > > See [this > comment|https://issues.apache.org/jira/browse/VELOCITY-542?focusedCommentId=16621819&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16621819] > : > {code} > #macro(testmacro $parameter) > $parameter > #end > #testmacro($return) > {code} > bq. which used to print "$return" (when $return is null or undefined) and we > now get "$parameter". > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-904) Add a flag for better backward compatibility with null macro arguments
[ https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17021301#comment-17021301 ] Thomas Mortagne commented on VELOCITY-904: -- OK great it was a tricky one to explain :) > Add a flag for better backward compatibility with null macro arguments > -- > > Key: VELOCITY-904 > URL: https://issues.apache.org/jira/browse/VELOCITY-904 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.0 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Minor > Fix For: 2.2 > > > See [this > comment|https://issues.apache.org/jira/browse/VELOCITY-542?focusedCommentId=16621819&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16621819] > : > {code} > #macro(testmacro $parameter) > $parameter > #end > #testmacro($return) > {code} > bq. which used to print "$return" (when $return is null or undefined) and we > now get "$parameter". > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Created] (VELOCITY-925) Macro calls without parenthesis now "eats" the following newline
Thomas Mortagne created VELOCITY-925: Summary: Macro calls without parenthesis now "eats" the following newline Key: VELOCITY-925 URL: https://issues.apache.org/jira/browse/VELOCITY-925 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 2.1 Reporter: Thomas Mortagne The behavior of macro calls without parenthesis changed in 2.x. I cannot find anything in the changelog about that but maybe I missed it. The following: {code} #macro(mymacro)value#end #mymacro {code} produces: * in Velocity 1.7: "value/n" * in Velocity 2.x: "value" but: {code} #macro(mymacro)value#end #mymacro() {code} produces in both Velocity versions "value" (eats the newline) Looks like omitting parenthesis in Velocity 1.7 was making the macro call "inline" while having them was eating the following newline like things like #set directive do. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-926) Regression: Macro arguments names cannot collide with external references names
[ https://issues.apache.org/jira/browse/VELOCITY-926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17022288#comment-17022288 ] Thomas Mortagne commented on VELOCITY-926: -- bq. Thanks again to Thomas Mortagne for finding this bug. Thanks you for the quick fix ! > Regression: Macro arguments names cannot collide with external references > names > --- > > Key: VELOCITY-926 > URL: https://issues.apache.org/jira/browse/VELOCITY-926 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.0, 2.1 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Major > Fix For: 2.2 > > > Consider the following example: > {code} > #macro( test $foo $bar ) > $foo $bar > #end > #set($foo = 'foo') > #set($bar = 'bar') > #test( $bar, $foo ) > {code} > The expected result would be "{{bar foo}}", but since 2.0 we get the > incorrect result "{{bar bar}}", as if the first inner {{$foo}} macro argument > was overwritting the second argument evaluation. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-925) Macro calls without parenthesis now "eats" the following newline
[ https://issues.apache.org/jira/browse/VELOCITY-925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17022747#comment-17022747 ] Thomas Mortagne commented on VELOCITY-925: -- bq. Commit 1873088 fixes the behavior under the parser.space_gobbling=bc mode. OK thanks. I indeed forgot to mention I'm using bc space gobbling. > Macro calls without parenthesis now "eats" the following newline > > > Key: VELOCITY-925 > URL: https://issues.apache.org/jira/browse/VELOCITY-925 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.1 >Reporter: Thomas Mortagne >Assignee: Claude Brisson >Priority: Major > Fix For: 2.2 > > > The behavior of macro calls without parenthesis changed in 2.x. I cannot find > anything in the changelog about that but maybe I missed it. > The following: > {code} > #macro(mymacro)value#end > #mymacro > {code} > produces: > * in Velocity 1.7: "value/n" > * in Velocity 2.x: "value" > but: > {code} > #macro(mymacro)value#end > #mymacro() > {code} > produces in both Velocity versions "value" (eats the newline) > Looks like omitting parenthesis in Velocity 1.7 was making the macro call > "inline" while having them was eating the following newline like things like > #set directive do. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-926) Regression: Macro arguments names cannot collide with external references names
[ https://issues.apache.org/jira/browse/VELOCITY-926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17023076#comment-17023076 ] Thomas Mortagne commented on VELOCITY-926: -- Seems this had a side effect: The following: {code} #macro (myMacro $myvar) $myvar #end #set ($myvar = "value") #myMacro() {code} produces: * Before VELOCITY-926 and in 1.7: "value" * After VELOCITY-926: $foobar > Regression: Macro arguments names cannot collide with external references > names > --- > > Key: VELOCITY-926 > URL: https://issues.apache.org/jira/browse/VELOCITY-926 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.0, 2.1 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Major > Fix For: 2.2 > > > Consider the following example: > {code} > #macro( test $foo $bar ) > $foo $bar > #end > #set($foo = 'foo') > #set($bar = 'bar') > #test( $bar, $foo ) > {code} > The expected result would be "{{bar foo}}", but since 2.0 we get the > incorrect result "{{bar bar}}", as if the first inner {{$foo}} macro argument > was overwritting the second argument evaluation. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-926) Regression: Macro arguments names cannot collide with external references names
[ https://issues.apache.org/jira/browse/VELOCITY-926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17023139#comment-17023139 ] Thomas Mortagne commented on VELOCITY-926: -- bq. Could you give me an example where the former behavior would be important for backward compatibility? Any change is important for backward compatibility. As usuall I'm not discussing how valid this behavior is but the fact that this behavior is expected and will break things. > Regression: Macro arguments names cannot collide with external references > names > --- > > Key: VELOCITY-926 > URL: https://issues.apache.org/jira/browse/VELOCITY-926 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.0, 2.1 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Major > Fix For: 2.2 > > > Consider the following example: > {code} > #macro( test $foo $bar ) > $foo $bar > #end > #set($foo = 'foo') > #set($bar = 'bar') > #test( $bar, $foo ) > {code} > The expected result would be "{{bar foo}}", but since 2.0 we get the > incorrect result "{{bar bar}}", as if the first inner {{$foo}} macro argument > was overwritting the second argument evaluation. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-926) Regression: Macro arguments names cannot collide with external references names
[ https://issues.apache.org/jira/browse/VELOCITY-926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17023139#comment-17023139 ] Thomas Mortagne edited comment on VELOCITY-926 at 1/24/20 5:46 PM: --- bq. Could you give me an example where the former behavior would be important for backward compatibility? Any change is important for backward compatibility. As usual I'm not discussing how valid this behavior is but the fact that this behavior is expected and will break things. was (Author: tmortagne): bq. Could you give me an example where the former behavior would be important for backward compatibility? Any change is important for backward compatibility. As usuall I'm not discussing how valid this behavior is but the fact that this behavior is expected and will break things. > Regression: Macro arguments names cannot collide with external references > names > --- > > Key: VELOCITY-926 > URL: https://issues.apache.org/jira/browse/VELOCITY-926 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.0, 2.1 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Major > Fix For: 2.2 > > > Consider the following example: > {code} > #macro( test $foo $bar ) > $foo $bar > #end > #set($foo = 'foo') > #set($bar = 'bar') > #test( $bar, $foo ) > {code} > The expected result would be "{{bar foo}}", but since 2.0 we get the > incorrect result "{{bar bar}}", as if the first inner {{$foo}} macro argument > was overwritting the second argument evaluation. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-926) Regression: Macro arguments names cannot collide with external references names
[ https://issues.apache.org/jira/browse/VELOCITY-926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17023076#comment-17023076 ] Thomas Mortagne edited comment on VELOCITY-926 at 1/27/20 8:00 AM: --- Seems this had a side effect: The following: {code} #macro (myMacro $myvar) $myvar #end #set ($myvar = "value") #myMacro() {code} produces: * Before VELOCITY-926 and in 1.7: "value" * After VELOCITY-926: $myvar was (Author: tmortagne): Seems this had a side effect: The following: {code} #macro (myMacro $myvar) $myvar #end #set ($myvar = "value") #myMacro() {code} produces: * Before VELOCITY-926 and in 1.7: "value" * After VELOCITY-926: $foobar > Regression: Macro arguments names cannot collide with external references > names > --- > > Key: VELOCITY-926 > URL: https://issues.apache.org/jira/browse/VELOCITY-926 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.0, 2.1 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Major > Fix For: 2.2 > > > Consider the following example: > {code} > #macro( test $foo $bar ) > $foo $bar > #end > #set($foo = 'foo') > #set($bar = 'bar') > #test( $bar, $foo ) > {code} > The expected result would be "{{bar foo}}", but since 2.0 we get the > incorrect result "{{bar bar}}", as if the first inner {{$foo}} macro argument > was overwritting the second argument evaluation. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-926) Regression: Macro arguments names cannot collide with external references names
[ https://issues.apache.org/jira/browse/VELOCITY-926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17024342#comment-17024342 ] Thomas Mortagne commented on VELOCITY-926: -- bq. That's why I was asking for a specific use case What I can tell you is that we did fixed several codes in XWiki Standard doing that but I agree with you that it was mistakes in both cases. So yes I don't have a strong use case to describe but any weird behavior always end up being expected and used in 10 years :) > Regression: Macro arguments names cannot collide with external references > names > --- > > Key: VELOCITY-926 > URL: https://issues.apache.org/jira/browse/VELOCITY-926 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.0, 2.1 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Major > Fix For: 2.2 > > > Consider the following example: > {code} > #macro( test $foo $bar ) > $foo $bar > #end > #set($foo = 'foo') > #set($bar = 'bar') > #test( $bar, $foo ) > {code} > The expected result would be "{{bar foo}}", but since 2.0 we get the > incorrect result "{{bar bar}}", as if the first inner {{$foo}} macro argument > was overwritting the second argument evaluation. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-926) Regression: Macro arguments names cannot collide with external references names
[ https://issues.apache.org/jira/browse/VELOCITY-926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17024342#comment-17024342 ] Thomas Mortagne edited comment on VELOCITY-926 at 1/27/20 1:38 PM: --- bq. That's why I was asking for a specific use case What I can tell you is that we did fixed several codes in XWiki Standard doing that but I agree with you that it was mistakes in both cases. So yes I don't have a strong use case to describe but any weird behavior always end up being expected and used in 10 years :) From what I understand the reason for this behavior in 1.7 is a side effect of the local macro context which does not exist anymore and I guess it not really easy to get back this behavior without getting back the local macro context which you said you did not wanted anymore even as a retro compatible option. was (Author: tmortagne): bq. That's why I was asking for a specific use case What I can tell you is that we did fixed several codes in XWiki Standard doing that but I agree with you that it was mistakes in both cases. So yes I don't have a strong use case to describe but any weird behavior always end up being expected and used in 10 years :) > Regression: Macro arguments names cannot collide with external references > names > --- > > Key: VELOCITY-926 > URL: https://issues.apache.org/jira/browse/VELOCITY-926 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.0, 2.1 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Major > Fix For: 2.2 > > > Consider the following example: > {code} > #macro( test $foo $bar ) > $foo $bar > #end > #set($foo = 'foo') > #set($bar = 'bar') > #test( $bar, $foo ) > {code} > The expected result would be "{{bar foo}}", but since 2.0 we get the > incorrect result "{{bar bar}}", as if the first inner {{$foo}} macro argument > was overwritting the second argument evaluation. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-926) Regression: Macro arguments names cannot collide with external references names
[ https://issues.apache.org/jira/browse/VELOCITY-926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17024342#comment-17024342 ] Thomas Mortagne edited comment on VELOCITY-926 at 1/27/20 1:39 PM: --- bq. That's why I was asking for a specific use case What I can tell you is that we did fixed several codes in XWiki Standard doing that but I agree with you that it was mistakes in both cases. So yes I don't have a strong use case to describe but any weird behavior always end up being expected and used in 10 years :) From what I understand the reason for this behavior in 1.7 is a side effect of the local macro context (the macro parameter being unset in the local context but variables were also fallbacking to global context when unset) which does not exist anymore and I guess it not really easy to get back this behavior without getting back the local macro context which you said you did not wanted anymore even as a retro compatible option. was (Author: tmortagne): bq. That's why I was asking for a specific use case What I can tell you is that we did fixed several codes in XWiki Standard doing that but I agree with you that it was mistakes in both cases. So yes I don't have a strong use case to describe but any weird behavior always end up being expected and used in 10 years :) From what I understand the reason for this behavior in 1.7 is a side effect of the local macro context which does not exist anymore and I guess it not really easy to get back this behavior without getting back the local macro context which you said you did not wanted anymore even as a retro compatible option. > Regression: Macro arguments names cannot collide with external references > names > --- > > Key: VELOCITY-926 > URL: https://issues.apache.org/jira/browse/VELOCITY-926 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.0, 2.1 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Major > Fix For: 2.2 > > > Consider the following example: > {code} > #macro( test $foo $bar ) > $foo $bar > #end > #set($foo = 'foo') > #set($bar = 'bar') > #test( $bar, $foo ) > {code} > The expected result would be "{{bar foo}}", but since 2.0 we get the > incorrect result "{{bar bar}}", as if the first inner {{$foo}} macro argument > was overwritting the second argument evaluation. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-926) Regression: Macro arguments names cannot collide with external references names
[ https://issues.apache.org/jira/browse/VELOCITY-926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17024342#comment-17024342 ] Thomas Mortagne edited comment on VELOCITY-926 at 1/27/20 1:46 PM: --- bq. That's why I was asking for a specific use case What I can tell you is that we did fixed several codes in XWiki Standard doing that but I agree with you that it was mistakes in both cases. So yes I don't have a strong use case to describe but any weird behavior always end up being expected and used in 10 years :) From what I understand the reason for this behavior in 1.7 is a side effect of the local macro context (the macro parameter being null the local context but variables were also fallbacking to global context when unset) which does not exist anymore and I guess it not really easy to get back this behavior without getting back the local macro context which you said you did not wanted anymore even as a retro compatible option. was (Author: tmortagne): bq. That's why I was asking for a specific use case What I can tell you is that we did fixed several codes in XWiki Standard doing that but I agree with you that it was mistakes in both cases. So yes I don't have a strong use case to describe but any weird behavior always end up being expected and used in 10 years :) From what I understand the reason for this behavior in 1.7 is a side effect of the local macro context (the macro parameter being unset in the local context but variables were also fallbacking to global context when unset) which does not exist anymore and I guess it not really easy to get back this behavior without getting back the local macro context which you said you did not wanted anymore even as a retro compatible option. > Regression: Macro arguments names cannot collide with external references > names > --- > > Key: VELOCITY-926 > URL: https://issues.apache.org/jira/browse/VELOCITY-926 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.0, 2.1 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Major > Fix For: 2.2 > > > Consider the following example: > {code} > #macro( test $foo $bar ) > $foo $bar > #end > #set($foo = 'foo') > #set($bar = 'bar') > #test( $bar, $foo ) > {code} > The expected result would be "{{bar foo}}", but since 2.0 we get the > incorrect result "{{bar bar}}", as if the first inner {{$foo}} macro argument > was overwritting the second argument evaluation. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-926) Regression: Macro arguments names cannot collide with external references names
[ https://issues.apache.org/jira/browse/VELOCITY-926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17024437#comment-17024437 ] Thomas Mortagne edited comment on VELOCITY-926 at 1/27/20 3:39 PM: --- bq. global values provide defaults for missing arguments Sounds good to me. It would be enough to cover https://issues.apache.org/jira/browse/VELOCITY-926?focusedCommentId=17023076&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17023076. Even if it does not cover the other use cases discussed on the mailing list regarding the macro local context it's still better than nothing. was (Author: tmortagne): bq. global values provide defaults for missing arguments Sounds good to me. It would be enough to cover https://issues.apache.org/jira/browse/VELOCITY-926?focusedCommentId=17023076&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17023076. Even if it does not cover the other use cases discussed on the mailing list regarding the macro local context it's better still better than nothing. > Regression: Macro arguments names cannot collide with external references > names > --- > > Key: VELOCITY-926 > URL: https://issues.apache.org/jira/browse/VELOCITY-926 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.0, 2.1 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Major > Fix For: 2.2 > > > Consider the following example: > {code} > #macro( test $foo $bar ) > $foo $bar > #end > #set($foo = 'foo') > #set($bar = 'bar') > #test( $bar, $foo ) > {code} > The expected result would be "{{bar foo}}", but since 2.0 we get the > incorrect result "{{bar bar}}", as if the first inner {{$foo}} macro argument > was overwritting the second argument evaluation. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-926) Regression: Macro arguments names cannot collide with external references names
[ https://issues.apache.org/jira/browse/VELOCITY-926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17024437#comment-17024437 ] Thomas Mortagne commented on VELOCITY-926: -- bq. global values provide defaults for missing arguments Sounds good to me. It would be enough to cover https://issues.apache.org/jira/browse/VELOCITY-926?focusedCommentId=17023076&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17023076. Even if it does not cover the other use cases discussed on the mailing list regarding the macro local context it's better still better than nothing. > Regression: Macro arguments names cannot collide with external references > names > --- > > Key: VELOCITY-926 > URL: https://issues.apache.org/jira/browse/VELOCITY-926 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.0, 2.1 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Major > Fix For: 2.2 > > > Consider the following example: > {code} > #macro( test $foo $bar ) > $foo $bar > #end > #set($foo = 'foo') > #set($bar = 'bar') > #test( $bar, $foo ) > {code} > The expected result would be "{{bar foo}}", but since 2.0 we get the > incorrect result "{{bar bar}}", as if the first inner {{$foo}} macro argument > was overwritting the second argument evaluation. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-926) Regression: Macro arguments names cannot collide with external references names
[ https://issues.apache.org/jira/browse/VELOCITY-926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17024437#comment-17024437 ] Thomas Mortagne edited comment on VELOCITY-926 at 1/27/20 3:47 PM: --- bq. global values provide defaults for missing arguments Sounds good to me. It would be enough to cover https://issues.apache.org/jira/browse/VELOCITY-926?focusedCommentId=17023076&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17023076. Even if it does not cover the other use cases discussed on the mailing list regarding the macro local context it's still better than nothing (at least we can say "hey it's Velocity's fault, we tried" and have a good excuse to have a simpler behavior ;)). was (Author: tmortagne): bq. global values provide defaults for missing arguments Sounds good to me. It would be enough to cover https://issues.apache.org/jira/browse/VELOCITY-926?focusedCommentId=17023076&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17023076. Even if it does not cover the other use cases discussed on the mailing list regarding the macro local context it's still better than nothing. > Regression: Macro arguments names cannot collide with external references > names > --- > > Key: VELOCITY-926 > URL: https://issues.apache.org/jira/browse/VELOCITY-926 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.0, 2.1 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Major > Fix For: 2.2 > > > Consider the following example: > {code} > #macro( test $foo $bar ) > $foo $bar > #end > #set($foo = 'foo') > #set($bar = 'bar') > #test( $bar, $foo ) > {code} > The expected result would be "{{bar foo}}", but since 2.0 we get the > incorrect result "{{bar bar}}", as if the first inner {{$foo}} macro argument > was overwritting the second argument evaluation. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-926) Regression: Macro arguments names cannot collide with external references names
[ https://issues.apache.org/jira/browse/VELOCITY-926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17025068#comment-17025068 ] Thomas Mortagne commented on VELOCITY-926: -- Looks good for the tested expected Velocity behaviors (AKA xwiki-commons-velocity unit tests). We'll know more about kind of expected but not directly tested ones after all XWiki integration tests are executed in a couple of hours. > Regression: Macro arguments names cannot collide with external references > names > --- > > Key: VELOCITY-926 > URL: https://issues.apache.org/jira/browse/VELOCITY-926 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.0, 2.1 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Major > Fix For: 2.2 > > > Consider the following example: > {code} > #macro( test $foo $bar ) > $foo $bar > #end > #set($foo = 'foo') > #set($bar = 'bar') > #test( $bar, $foo ) > {code} > The expected result would be "{{bar foo}}", but since 2.0 we get the > incorrect result "{{bar bar}}", as if the first inner {{$foo}} macro argument > was overwritting the second argument evaluation. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-926) Regression: Macro arguments names cannot collide with external references names
[ https://issues.apache.org/jira/browse/VELOCITY-926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17025402#comment-17025402 ] Thomas Mortagne commented on VELOCITY-926: -- bq. We'll know more about kind of expected but not directly tested ones after all XWiki integration tests are executed in a couple of hours. Looks OK on that front too from what we can see. Well done :) > Regression: Macro arguments names cannot collide with external references > names > --- > > Key: VELOCITY-926 > URL: https://issues.apache.org/jira/browse/VELOCITY-926 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.0, 2.1 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Major > Fix For: 2.2 > > > Consider the following example: > {code} > #macro( test $foo $bar ) > $foo $bar > #end > #set($foo = 'foo') > #set($bar = 'bar') > #test( $bar, $foo ) > {code} > The expected result would be "{{bar foo}}", but since 2.0 we get the > incorrect result "{{bar bar}}", as if the first inner {{$foo}} macro argument > was overwritting the second argument evaluation. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-929) Improper SLF4J dependency
[ https://issues.apache.org/jira/browse/VELOCITY-929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17134761#comment-17134761 ] Thomas Mortagne commented on VELOCITY-929: -- There is no reason to make the slf4j-api dependency provided. Maven will select in priority your own slf4j dependency version since Maven selec > Improper SLF4J dependency > - > > Key: VELOCITY-929 > URL: https://issues.apache.org/jira/browse/VELOCITY-929 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.2 >Reporter: Mantas Gridinas >Priority: Minor > > Currently, velocity-engine-core defines a transitive dependency of > "slf4j-api" as a compile time dependency, rather than a non-transitive > compile time dependency as seen by snippet below > {code:xml} > > org.slf4j > slf4j-api > 1.7.30 > compile > > {code} > Instead, the dependency's scope should be provided. This prevents classpath > races and leaves it up to the user/developer to pull in the necessary slf4j > API dependency for their project. > Currently I use the following workaround to exclude the slf4j dependency > {code:xml} > > org.apache.velocity > velocity-engine-core > 2.2 > > > org.slf4j > slf4j-api > > > > {code} -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-929) Improper SLF4J dependency
[ https://issues.apache.org/jira/browse/VELOCITY-929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17134761#comment-17134761 ] Thomas Mortagne edited comment on VELOCITY-929 at 6/13/20, 11:25 AM: - There is no reason to make the slf4j-api dependency provided. Maven will select in priority your own slf4j dependency version since Maven select the dependency closest to the root of the dependency tree in case of conflict. was (Author: tmortagne): There is no reason to make the slf4j-api dependency provided. Maven will select in priority your own slf4j dependency version since Maven selec > Improper SLF4J dependency > - > > Key: VELOCITY-929 > URL: https://issues.apache.org/jira/browse/VELOCITY-929 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.2 >Reporter: Mantas Gridinas >Priority: Minor > > Currently, velocity-engine-core defines a transitive dependency of > "slf4j-api" as a compile time dependency, rather than a non-transitive > compile time dependency as seen by snippet below > {code:xml} > > org.slf4j > slf4j-api > 1.7.30 > compile > > {code} > Instead, the dependency's scope should be provided. This prevents classpath > races and leaves it up to the user/developer to pull in the necessary slf4j > API dependency for their project. > Currently I use the following workaround to exclude the slf4j dependency > {code:xml} > > org.apache.velocity > velocity-engine-core > 2.2 > > > org.slf4j > slf4j-api > > > > {code} -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-945) Error Configuring Velocity
[ https://issues.apache.org/jira/browse/VELOCITY-945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17353005#comment-17353005 ] Thomas Mortagne commented on VELOCITY-945: -- [~prs725] it feels like you should ask on Wildfly side since it seems to be a problem in the way Wildfly uses Velocity, we can hardly help you here if you don't give more Velocity related information. > Error Configuring Velocity > --- > > Key: VELOCITY-945 > URL: https://issues.apache.org/jira/browse/VELOCITY-945 > Project: Velocity > Issue Type: Task > Components: Engine >Affects Versions: 2.3 > Environment: Software platform >Reporter: Pooja >Priority: Major > > When upgrading Wildfly Server to 20, we get a error configuring velocity > error every second build. The error does not occur on the first build or if > the subsequent builds have code changes. But if deploying multiple times, the > error occurs intermittently. > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Created] (VELOCITY-952) Velocity is calling the "wrong" Method
Thomas Mortagne created VELOCITY-952: Summary: Velocity is calling the "wrong" Method Key: VELOCITY-952 URL: https://issues.apache.org/jira/browse/VELOCITY-952 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 2.3 Reporter: Thomas Mortagne OK, the title is maybe a bit harsh, but it catches the eyes :) At XWiki we recently started testing on Java 17 to see if there is any problem which leaded us to add things like {{--add-opens java.base/java.util=ALL-UNNAMED}} but Velocity happen to be the source of another problem related to the new module world. When doing something like {{$datetool.timeZone.getOffset(0)}} ($datetool being the org.apache.velocity.tools.generic.DateTool) we get the following error: {noformat} ... Caused by: java.lang.IllegalAccessException: class org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl cannot access class sun.util.calendar.ZoneInfo (in module java.base) because module java.base does not export sun.util.calendar to unnamed module @7ca16adc at java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:392) at java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674) at java.base/java.lang.reflect.Method.invoke(Method.java:560) at org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:571) at org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:554) at org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:221) ... 199 more {noformat} The reason is that while the developer intent/expectation was to call "java.util.TimeZone#getOffset(0)" what Velocity really called from JVM point of view is "sun.util.calendar.ZoneInfo.getOffset(0)" directly. That's because Velocity is doing (I assume, since I did not check the exact code) the equivalent of: {{noformat}} java.util.TimeZone.getDefault().getClass().getMethod("getOffset", long.class).invoke(TimeZone.getDefault(), 0); {{noformat}} which is itself the equivalent of: {{noformat}} sun.util.calendar.ZoneInfo.class.getMethod("getOffset", long.class).invoke(TimeZone.getDefault(), 0); {{noformat}} I guess the only way to fix this would be to track down the lowest overridden Method (I agree, it might not always be easy to choose between two interfaces declaring a method with the same signature, but choosing the first one we find from the same hierarchy level is still better than nothing) and call that one instead. With the use case used as example in this issue, that would mean ending up doing the equivalent of: {{noformat}} java.util.TimeZone.class.getMethod("getOffset", long.class).invoke(TimeZone.getDefault(), 0); {{noformat}} which, from JVM point of view, is covered by the {{--add-opens java.base/java.util=ALL-UNNAMED}}. It would be a big change, but at least can't think of any retro-compatibility problem it might cause. One might be tempted to answer "just add {{--add-opens java.base/sun.util.calendar=ALL-UNNAMED}}" but it does not seem fair as this is not what the API that the script uses was exposing at all, you might need to document a different one for each JVM implementation (even if it's probably unlikely for this specific example) but more importantly you will potentially need quite a lot of those and will only discover it at runtime since it's not so easy to guess from an API in which you only know the public JVM classes since that's what you manipulate. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-952) Velocity is calling the "wrong" Method
[ https://issues.apache.org/jira/browse/VELOCITY-952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mortagne updated VELOCITY-952: - Description: OK, the title is maybe a bit harsh, but it catches the eyes :) At XWiki we recently started testing on Java 17 to see if there is any problem which leaded us to add things like {{--add-opens java.base/java.util=ALL-UNNAMED}} but Velocity happen to be the source of another problem related to the new module world. When doing something like {{$datetool.timeZone.getOffset(0)}} ($datetool being the org.apache.velocity.tools.generic.DateTool) we get the following error: {noformat} ... Caused by: java.lang.IllegalAccessException: class org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl cannot access class sun.util.calendar.ZoneInfo (in module java.base) because module java.base does not export sun.util.calendar to unnamed module @7ca16adc at java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:392) at java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674) at java.base/java.lang.reflect.Method.invoke(Method.java:560) at org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:571) at org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:554) at org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:221) ... 199 more {noformat} The reason is that while the developer intent/expectation was to call "java.util.TimeZone#getOffset(0)" what Velocity really called from JVM point of view is "sun.util.calendar.ZoneInfo.getOffset(0)" directly. That's because Velocity is doing (I assume, since I did not check the exact code) the equivalent of: {{noformat}} java.util.TimeZone.getDefault().getClass().getMethod("getOffset", long.class).invoke(TimeZone.getDefault(), 0); {{noformat}} which is itself the equivalent of: {{noformat}} sun.util.calendar.ZoneInfo.class.getMethod("getOffset", long.class).invoke(TimeZone.getDefault(), 0); {{noformat}} I guess the only way to fix this would be to track down the lowest overridden Method (I agree, it might not always be easy to choose between two interfaces declaring a method with the same signature, but choosing the first one we find from the same hierarchy level is still better than nothing) and call that one instead. With the use case used as example in this issue, that would mean ending up doing the equivalent of: {{noformat}} java.util.TimeZone.class.getMethod("getOffset", long.class).invoke(TimeZone.getDefault(), 0); {{noformat}} which, from JVM point of view, is covered by the {{--add-opens java.base/java.util=ALL-UNNAMED}}. It would be a big change, but at least can't think of any retro-compatibility problem it might cause. One might be tempted to answer "just add {{--add-opens java.base/sun.util.calendar=ALL-UNNAMED}}" but it does not seem fair as this is not what the API that the script uses was exposing at all, you might need to document a different one for each JVM implementation (even if it's probably unlikely for this specific example) but more importantly you will potentially need quite a lot of those and will only discover it at runtime since it's not so easy to guess from an API in which you only know the public JVM classes since that's what you manipulate. I would be happy to work on this, but I wanted first ask what others think about this problem in general and the possible solutions I may have missed. was: OK, the title is maybe a bit harsh, but it catches the eyes :) At XWiki we recently started testing on Java 17 to see if there is any problem which leaded us to add things like {{--add-opens java.base/java.util=ALL-UNNAMED}} but Velocity happen to be the source of another problem related to the new module world. When doing something like {{$datetool.timeZone.getOffset(0)}} ($datetool being the org.apache.velocity.tools.generic.DateTool) we get the following error: {noformat} ... Caused by: java.lang.IllegalAccessException: class org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl cannot access class sun.util.calendar.ZoneInfo (in module java.base) because module java.base does not export sun.util.calendar to unnamed module @7ca16adc at java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:392) at java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674) at java.base/java.lang.reflect.Method.invoke(Method.java:560) at org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:571) at org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:554) at org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:221) ... 199 more {noformat} The reason is t
[jira] [Commented] (VELOCITY-952) Velocity is calling the "wrong" method
[ https://issues.apache.org/jira/browse/VELOCITY-952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17504830#comment-17504830 ] Thomas Mortagne commented on VELOCITY-952: -- bq. respecting the method return type Carrying this information around with the object sounds like a complex thing to change (but maybe not, I don't know the Velocity AST very well), but I agree it's probably the most accurate. > Velocity is calling the "wrong" method > -- > > Key: VELOCITY-952 > URL: https://issues.apache.org/jira/browse/VELOCITY-952 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.3 >Reporter: Thomas Mortagne >Priority: Major > > OK, the title is maybe a bit harsh, but it catches the eyes :) > At XWiki we recently started testing on Java 17 to see if there is any > problem which leaded us to add things like {{--add-opens > java.base/java.util=ALL-UNNAMED}} but Velocity happen to be the source of > another problem related to the new module world. > When doing something like {{$datetool.timeZone.getOffset(0)}} ($datetool > being the org.apache.velocity.tools.generic.DateTool) we get the following > error: > {noformat} > ... > Caused by: java.lang.IllegalAccessException: class > org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl cannot > access class sun.util.calendar.ZoneInfo (in module java.base) because module > java.base does not export sun.util.calendar to unnamed module @7ca16adc > at > java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:392) > at > java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674) > at java.base/java.lang.reflect.Method.invoke(Method.java:560) > at > org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:571) > at > org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:554) > at > org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:221) > ... 199 more > {noformat} > The reason is that while the developer intent/expectation was to call > "java.util.TimeZone#getOffset(0)" what Velocity really called from JVM point > of view is "sun.util.calendar.ZoneInfo.getOffset(0)" directly. > That's because Velocity is doing (I assume, since I did not check the exact > code) the equivalent of: > {{noformat}} > java.util.TimeZone.getDefault().getClass().getMethod("getOffset", > long.class).invoke(TimeZone.getDefault(), 0); > {{noformat}} > which is itself the equivalent of: > {{noformat}} > sun.util.calendar.ZoneInfo.class.getMethod("getOffset", > long.class).invoke(TimeZone.getDefault(), 0); > {{noformat}} > I guess the only way to fix this would be to track down the lowest overridden > Method (I agree, it might not always be easy to choose between two interfaces > declaring a method with the same signature, but choosing the first one we > find from the same hierarchy level is still better than nothing) and call > that one instead. With the use case used as example in this issue, that would > mean ending up doing the equivalent of: > {{noformat}} > java.util.TimeZone.class.getMethod("getOffset", > long.class).invoke(TimeZone.getDefault(), 0); > {{noformat}} > which, from JVM point of view, is covered by the {{--add-opens > java.base/java.util=ALL-UNNAMED}}. > It would be a big change, but at least can't think of any retro-compatibility > problem it might cause. > One might be tempted to answer "just add {{--add-opens > java.base/sun.util.calendar=ALL-UNNAMED}}" but it does not seem fair as this > is not what the API that the script uses was exposing at all, you might need > to document a different one for each JVM implementation (even if it's > probably unlikely for this specific example) but more importantly you will > potentially need quite a lot of those and will only discover it at runtime > since it's not so easy to guess from an API in which you only know the public > JVM classes since that's what you manipulate. > I would be happy to work on this, but I wanted first ask what others think > about this problem in general and the possible solutions I may have missed. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-952) Velocity is calling the "wrong" method
[ https://issues.apache.org/jira/browse/VELOCITY-952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mortagne updated VELOCITY-952: - Description: OK, the title is maybe a bit harsh, but it catches the eyes :) At XWiki we recently started testing on Java 17 to see if there is any problem which leaded us to add things like {{--add-opens java.base/java.util=ALL-UNNAMED}} but Velocity happen to be the source of another problem related to the new module world. When doing something like {{$datetool.timeZone.getOffset(0)}} ($datetool being the org.apache.velocity.tools.generic.DateTool) we get the following error: {noformat} ... Caused by: java.lang.IllegalAccessException: class org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl cannot access class sun.util.calendar.ZoneInfo (in module java.base) because module java.base does not export sun.util.calendar to unnamed module @7ca16adc at java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:392) at java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674) at java.base/java.lang.reflect.Method.invoke(Method.java:560) at org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:571) at org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:554) at org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:221) ... 199 more {noformat} The reason is that while the developer intent/expectation was to call "java.util.TimeZone#getOffset(0)" what Velocity really called from JVM point of view is "sun.util.calendar.ZoneInfo.getOffset(0)" directly. That's because Velocity is doing (I assume, since I did not check the exact code) the equivalent of: {noformat} java.util.TimeZone.getDefault().getClass().getMethod("getOffset", long.class).invoke(TimeZone.getDefault(), 0); {noformat} which is itself the equivalent of: {noformat} sun.util.calendar.ZoneInfo.class.getMethod("getOffset", long.class).invoke(TimeZone.getDefault(), 0); {noformat} I guess the only way to fix this would be to track down the lowest overridden Method (I agree, it might not always be easy to choose between two interfaces declaring a method with the same signature, but choosing the first one we find from the same hierarchy level is still better than nothing) and call that one instead. With the use case used as example in this issue, that would mean ending up doing the equivalent of: {noformat} java.util.TimeZone.class.getMethod("getOffset", long.class).invoke(TimeZone.getDefault(), 0); {noformat} which, from JVM point of view, is covered by the {{--add-opens java.base/java.util=ALL-UNNAMED}}. It would be a big change, but at least can't think of any retro-compatibility problem it might cause. One might be tempted to answer "just add {{--add-opens java.base/sun.util.calendar=ALL-UNNAMED}}" but it does not seem fair as this is not what the API that the script uses was exposing at all, you might need to document a different one for each JVM implementation (even if it's probably unlikely for this specific example) but more importantly you will potentially need quite a lot of those and will only discover it at runtime since it's not so easy to guess from an API in which you only know the public JVM classes since that's what you manipulate. I would be happy to work on this, but I wanted first ask what others think about this problem in general and the possible solutions I may have missed. was: OK, the title is maybe a bit harsh, but it catches the eyes :) At XWiki we recently started testing on Java 17 to see if there is any problem which leaded us to add things like {{--add-opens java.base/java.util=ALL-UNNAMED}} but Velocity happen to be the source of another problem related to the new module world. When doing something like {{$datetool.timeZone.getOffset(0)}} ($datetool being the org.apache.velocity.tools.generic.DateTool) we get the following error: {noformat} ... Caused by: java.lang.IllegalAccessException: class org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl cannot access class sun.util.calendar.ZoneInfo (in module java.base) because module java.base does not export sun.util.calendar to unnamed module @7ca16adc at java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:392) at java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674) at java.base/java.lang.reflect.Method.invoke(Method.java:560) at org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:571) at org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:554) at org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:221) ... 199 more {noformat} The reason is that while th
[jira] [Commented] (VELOCITY-952) Velocity is calling the "wrong" method
[ https://issues.apache.org/jira/browse/VELOCITY-952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17710993#comment-17710993 ] Thomas Mortagne commented on VELOCITY-952: -- {quote} bq. respecting the method return type Carrying this information around with the object sounds like a complex thing to change (but maybe not, I don't know the Velocity AST very well), but I agree it's probably the most accurate. {quote} So I finally did some digging on what it would take to implement this idea, and it's indeed not trivial. From what I understood, the problem is that here is no way to associate metadata to a value in the context right now, so all the APIs which manipulate the value of a variable don't have any way to pass/return more info about this value (thinking especially about associating a Type with the value in the Context and how to return a Type along with the value returned by ASTMethod#execute. I started by refactoring a bit {{org.apache.velocity.context.Context}} to support associating metadata to an entry without breaking existing API, but then the number of things to change in pretty critical places to take this into account is a bit overwhelming for me and a huge challenge in terms of retro compatibly without really knowing if that's really the direction that you guys want to take. Problem is that this bug makes pretty much impossible to say that XWiki supports Java 17 because of the many unforeseen IllegalAccessException failures you can end up with depending on which apparently standard Java API you are manipulating in a script. So for now my plan is to workaround this with an uberspector on XWiki side doing what I initially proposed: try to find the lowest overwritten Method (which, I agree, is not the best and not something I would recommend on standard Velocity side compared to the "carry the return type around with the value" idea). > Velocity is calling the "wrong" method > -- > > Key: VELOCITY-952 > URL: https://issues.apache.org/jira/browse/VELOCITY-952 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.3 >Reporter: Thomas Mortagne >Priority: Major > > OK, the title is maybe a bit harsh, but it catches the eyes :) > At XWiki we recently started testing on Java 17 to see if there is any > problem which leaded us to add things like {{--add-opens > java.base/java.util=ALL-UNNAMED}} but Velocity happen to be the source of > another problem related to the new module world. > When doing something like {{$datetool.timeZone.getOffset(0)}} ($datetool > being the org.apache.velocity.tools.generic.DateTool) we get the following > error: > {noformat} > ... > Caused by: java.lang.IllegalAccessException: class > org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl cannot > access class sun.util.calendar.ZoneInfo (in module java.base) because module > java.base does not export sun.util.calendar to unnamed module @7ca16adc > at > java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:392) > at > java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674) > at java.base/java.lang.reflect.Method.invoke(Method.java:560) > at > org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:571) > at > org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:554) > at > org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:221) > ... 199 more > {noformat} > The reason is that while the developer intent/expectation was to call > "java.util.TimeZone#getOffset(0)" what Velocity really called from JVM point > of view is "sun.util.calendar.ZoneInfo.getOffset(0)" directly. > That's because Velocity is doing (I assume, since I did not check the exact > code) the equivalent of: > {noformat} > java.util.TimeZone.getDefault().getClass().getMethod("getOffset", > long.class).invoke(TimeZone.getDefault(), 0); > {noformat} > which is itself the equivalent of: > {noformat} > sun.util.calendar.ZoneInfo.class.getMethod("getOffset", > long.class).invoke(TimeZone.getDefault(), 0); > {noformat} > I guess the only way to fix this would be to track down the lowest overridden > Method (I agree, it might not always be easy to choose between two interfaces > declaring a method with the same signature, but choosing the first one we > find from the same hierarchy level is still better than nothing) and call > that one instead. With the use case used as example in this issue, that would > mean ending up doing the equivalent of: > {noformat} > java.util.TimeZone.class.getMethod("getOffset", > long.class).invoke(TimeZone.getDefault(), 0); > {noformat} > which, from JVM point of view, is co