[jira] Created: (VELOCITY-735) Provide JSR 223 implementation

2009-09-03 Thread Thomas Mortagne (JIRA)
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

2011-05-17 Thread Thomas Mortagne (JIRA)
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] [Updated] (VELOCITY-896) Regression in the handling of String literal ending with a sharp

2018-06-13 Thread Thomas Mortagne (JIRA)


 [ 
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 

[jira] [Updated] (VELOCITY-896) Regression in the handling of String literal ending with a sharp

2018-06-13 Thread Thomas Mortagne (JIRA)


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

[jira] [Updated] (VELOCITY-896) Regression in the handling of String literal ending with a sharp sign

2018-06-13 Thread Thomas Mortagne (JIRA)


 [ 
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 

[jira] [Updated] (VELOCITY-896) Regression in the handling of String literal ending with a sharp sign

2018-06-13 Thread Thomas Mortagne (JIRA)


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

[jira] [Created] (VELOCITY-897) Regression in the handling of String literal ending with a dollar sign

2018-06-13 Thread Thomas Mortagne (JIRA)
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] [Created] (VELOCITY-896) Regression in the handling of string containing a sharp

2018-06-12 Thread Thomas Mortagne (JIRA)
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 

[jira] [Updated] (VELOCITY-896) Regression in the handling of string containing a sharp

2018-06-12 Thread Thomas Mortagne (JIRA)


 [ 
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

2018-06-12 Thread Thomas Mortagne (JIRA)


 [ 
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] [Created] (VELOCITY-892) Method arguments conversions should be based on Type instead of Class

2018-05-30 Thread Thomas Mortagne (JIRA)
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

2018-06-01 Thread Thomas Mortagne (JIRA)
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

2018-06-02 Thread Thomas Mortagne (JIRA)


 [ 
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

2018-06-02 Thread Thomas Mortagne (JIRA)


[ 
https://issues.apache.org/jira/browse/VELOCITY-894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [Comment Edited] (VELOCITY-900) Velocity.evalute thows an exception if the next char after a keyword is '_'

2018-09-06 Thread Thomas Mortagne (JIRA)


[ 
https://issues.apache.org/jira/browse/VELOCITY-900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 '_'

2018-09-06 Thread Thomas Mortagne (JIRA)


[ 
https://issues.apache.org/jira/browse/VELOCITY-900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 '_'

2018-09-06 Thread Thomas Mortagne (JIRA)


[ 
https://issues.apache.org/jira/browse/VELOCITY-900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2018-09-10 Thread Thomas Mortagne (JIRA)


[ 
https://issues.apache.org/jira/browse/VELOCITY-901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2018-09-10 Thread Thomas Mortagne (JIRA)


[ 
https://issues.apache.org/jira/browse/VELOCITY-901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2018-10-08 Thread Thomas Mortagne (JIRA)


[ 
https://issues.apache.org/jira/browse/VELOCITY-896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 
> 

[jira] [Commented] (VELOCITY-542) minus sign in #set requires spaces to surround it

2018-10-15 Thread Thomas Mortagne (JIRA)


[ 
https://issues.apache.org/jira/browse/VELOCITY-542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2018-10-15 Thread Thomas Mortagne (JIRA)


[ 
https://issues.apache.org/jira/browse/VELOCITY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2018-10-15 Thread Thomas Mortagne (JIRA)


[ 
https://issues.apache.org/jira/browse/VELOCITY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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-892) Method arguments conversions should be based on Type instead of Class

2018-10-17 Thread Thomas Mortagne (JIRA)


[ 
https://issues.apache.org/jira/browse/VELOCITY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2018-10-17 Thread Thomas Mortagne (JIRA)


[ 
https://issues.apache.org/jira/browse/VELOCITY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2018-10-17 Thread Thomas Mortagne (JIRA)


[ 
https://issues.apache.org/jira/browse/VELOCITY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2018-10-17 Thread Thomas Mortagne (JIRA)


[ 
https://issues.apache.org/jira/browse/VELOCITY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [Comment Edited] (VELOCITY-892) Method arguments conversions should be based on Type instead of Class

2018-10-17 Thread Thomas Mortagne (JIRA)


[ 
https://issues.apache.org/jira/browse/VELOCITY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2018-10-17 Thread Thomas Mortagne (JIRA)


[ 
https://issues.apache.org/jira/browse/VELOCITY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2018-10-17 Thread Thomas Mortagne (JIRA)


[ 
https://issues.apache.org/jira/browse/VELOCITY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2018-10-17 Thread Thomas Mortagne (JIRA)


[ 
https://issues.apache.org/jira/browse/VELOCITY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [Comment Edited] (VELOCITY-892) Method arguments conversions should be based on Type instead of Class

2018-10-18 Thread Thomas Mortagne (JIRA)


[ 
https://issues.apache.org/jira/browse/VELOCITY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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-892) Method arguments conversions should be based on Type instead of Class

2018-10-18 Thread Thomas Mortagne (JIRA)


[ 
https://issues.apache.org/jira/browse/VELOCITY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [Commented] (VELOCITY-892) Method arguments conversions should be based on Type instead of Class

2018-10-16 Thread Thomas Mortagne (JIRA)


[ 
https://issues.apache.org/jira/browse/VELOCITY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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-896) Regression in the handling of String literal ending with a sharp sign

2018-09-20 Thread Thomas Mortagne (JIRA)


[ 
https://issues.apache.org/jira/browse/VELOCITY-896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 

[jira] [Commented] (VELOCITY-896) Regression in the handling of String literal ending with a sharp sign

2018-09-20 Thread Thomas Mortagne (JIRA)


[ 
https://issues.apache.org/jira/browse/VELOCITY-896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 
> 

[jira] [Comment Edited] (VELOCITY-896) Regression in the handling of String literal ending with a sharp sign

2018-09-20 Thread Thomas Mortagne (JIRA)


[ 
https://issues.apache.org/jira/browse/VELOCITY-896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
>   at 
> 

[jira] [Commented] (VELOCITY-542) minus sign in #set requires spaces to surround it

2018-09-20 Thread Thomas Mortagne (JIRA)


[ 
https://issues.apache.org/jira/browse/VELOCITY-542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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-542) minus sign in #set requires spaces to surround it

2018-09-20 Thread Thomas Mortagne (JIRA)


[ 
https://issues.apache.org/jira/browse/VELOCITY-542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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-896) Regression in the handling of String literal ending with a sharp sign

2019-01-02 Thread Thomas Mortagne (JIRA)


[ 
https://issues.apache.org/jira/browse/VELOCITY-896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 
> 

[jira] [Comment Edited] (VELOCITY-896) Regression in the handling of String literal ending with a sharp sign

2019-01-02 Thread Thomas Mortagne (JIRA)


[ 
https://issues.apache.org/jira/browse/VELOCITY-896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 
> 

[jira] [Commented] (VELOCITY-918) Using commons-collection version 3.2.1 which having vulnerabilities

2019-07-16 Thread Thomas Mortagne (JIRA)


[ 
https://issues.apache.org/jira/browse/VELOCITY-918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2019-12-04 Thread Thomas Mortagne (Jira)


[ 
https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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=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

2019-12-09 Thread Thomas Mortagne (Jira)


[ 
https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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=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

2019-12-09 Thread Thomas Mortagne (Jira)


[ 
https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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=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

2019-12-10 Thread Thomas Mortagne (Jira)
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

2019-12-10 Thread Thomas Mortagne (Jira)


 [ 
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

2019-12-10 Thread Thomas Mortagne (Jira)


 [ 
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

2019-12-10 Thread Thomas Mortagne (Jira)


 [ 
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

2019-12-10 Thread Thomas Mortagne (Jira)


 [ 
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] [Comment Edited] (VELOCITY-904) Add a flag for better backward compatibility with null macro arguments

2019-12-13 Thread Thomas Mortagne (Jira)


[ 
https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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=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

2019-12-13 Thread Thomas Mortagne (Jira)


[ 
https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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=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

2019-12-12 Thread Thomas Mortagne (Jira)


[ 
https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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=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

2019-12-05 Thread Thomas Mortagne (Jira)


[ 
https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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=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-925) Macro calls without parenthesis now "eats" the following newline

2020-01-24 Thread Thomas Mortagne (Jira)


[ 
https://issues.apache.org/jira/browse/VELOCITY-925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [Comment Edited] (VELOCITY-926) Regression: Macro arguments names cannot collide with external references names

2020-01-27 Thread Thomas Mortagne (Jira)


[ 
https://issues.apache.org/jira/browse/VELOCITY-926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [Created] (VELOCITY-925) Macro calls without parenthesis now "eats" the following newline

2020-01-23 Thread Thomas Mortagne (Jira)
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] [Comment Edited] (VELOCITY-926) Regression: Macro arguments names cannot collide with external references names

2020-01-27 Thread Thomas Mortagne (Jira)


[ 
https://issues.apache.org/jira/browse/VELOCITY-926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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=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=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

2020-01-27 Thread Thomas Mortagne (Jira)


[ 
https://issues.apache.org/jira/browse/VELOCITY-926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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=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

2020-01-27 Thread Thomas Mortagne (Jira)


[ 
https://issues.apache.org/jira/browse/VELOCITY-926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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=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=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

2020-01-23 Thread Thomas Mortagne (Jira)


[ 
https://issues.apache.org/jira/browse/VELOCITY-926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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-926) Regression: Macro arguments names cannot collide with external references names

2020-01-24 Thread Thomas Mortagne (Jira)


[ 
https://issues.apache.org/jira/browse/VELOCITY-926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [Comment Edited] (VELOCITY-926) Regression: Macro arguments names cannot collide with external references names

2020-01-24 Thread Thomas Mortagne (Jira)


[ 
https://issues.apache.org/jira/browse/VELOCITY-926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [Commented] (VELOCITY-926) Regression: Macro arguments names cannot collide with external references names

2020-01-24 Thread Thomas Mortagne (Jira)


[ 
https://issues.apache.org/jira/browse/VELOCITY-926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [Commented] (VELOCITY-926) Regression: Macro arguments names cannot collide with external references names

2020-01-28 Thread Thomas Mortagne (Jira)


[ 
https://issues.apache.org/jira/browse/VELOCITY-926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2020-01-28 Thread Thomas Mortagne (Jira)


[ 
https://issues.apache.org/jira/browse/VELOCITY-926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [Comment Edited] (VELOCITY-926) Regression: Macro arguments names cannot collide with external references names

2020-01-27 Thread Thomas Mortagne (Jira)


[ 
https://issues.apache.org/jira/browse/VELOCITY-926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2020-01-27 Thread Thomas Mortagne (Jira)


[ 
https://issues.apache.org/jira/browse/VELOCITY-926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [Commented] (VELOCITY-926) Regression: Macro arguments names cannot collide with external references names

2020-01-27 Thread Thomas Mortagne (Jira)


[ 
https://issues.apache.org/jira/browse/VELOCITY-926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2020-01-27 Thread Thomas Mortagne (Jira)


[ 
https://issues.apache.org/jira/browse/VELOCITY-926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [Commented] (VELOCITY-924) Bad cache handling for java.lang.Class methods

2020-01-09 Thread Thomas Mortagne (Jira)


[ 
https://issues.apache.org/jira/browse/VELOCITY-924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2020-01-09 Thread Thomas Mortagne (Jira)


[ 
https://issues.apache.org/jira/browse/VELOCITY-924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [Comment Edited] (VELOCITY-924) Bad cache handling for java.lang.Class methods

2020-01-09 Thread Thomas Mortagne (Jira)


[ 
https://issues.apache.org/jira/browse/VELOCITY-924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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-924) Bad cache handling for java.lang.Class methods

2020-01-09 Thread Thomas Mortagne (Jira)


[ 
https://issues.apache.org/jira/browse/VELOCITY-924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [Commented] (VELOCITY-904) Add a flag for better backward compatibility with null macro arguments

2020-01-22 Thread Thomas Mortagne (Jira)


[ 
https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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=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

2020-01-22 Thread Thomas Mortagne (Jira)


[ 
https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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=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

2020-01-20 Thread Thomas Mortagne (Jira)


[ 
https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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=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

2020-01-20 Thread Thomas Mortagne (Jira)


[ 
https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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=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

2020-01-20 Thread Thomas Mortagne (Jira)


[ 
https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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=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

2020-01-20 Thread Thomas Mortagne (Jira)


[ 
https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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=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

2020-01-20 Thread Thomas Mortagne (Jira)


[ 
https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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=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

2020-01-20 Thread Thomas Mortagne (Jira)


[ 
https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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=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

2020-01-20 Thread Thomas Mortagne (Jira)


[ 
https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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=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] [Updated] (VELOCITY-924) Bad cache handling for java.lang.Class methods

2020-01-03 Thread Thomas Mortagne (Jira)


 [ 
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

2020-01-03 Thread Thomas Mortagne (Jira)


 [ 
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] [Created] (VELOCITY-924) Bad cache handling for java.lang.Class methods

2020-01-03 Thread Thomas Mortagne (Jira)
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] [Commented] (VELOCITY-924) Bad cache handling for java.lang.Class methods

2020-01-05 Thread Thomas Mortagne (Jira)


[ 
https://issues.apache.org/jira/browse/VELOCITY-924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [Commented] (VELOCITY-929) Improper SLF4J dependency

2020-06-13 Thread Thomas Mortagne (Jira)


[ 
https://issues.apache.org/jira/browse/VELOCITY-929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2020-06-13 Thread Thomas Mortagne (Jira)


[ 
https://issues.apache.org/jira/browse/VELOCITY-929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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