[jira] [Commented] (VELOCITY-970) velocity-engine-core contains commons-io Maven descriptor
[ https://issues.apache.org/jira/browse/VELOCITY-970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17805711#comment-17805711 ] Thomas Mortagne commented on VELOCITY-970: -- OK, I actually did not know the shade plugin was also modifying the pom. > velocity-engine-core contains commons-io Maven descriptor > - > > Key: VELOCITY-970 > URL: https://issues.apache.org/jira/browse/VELOCITY-970 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.3 >Reporter: Thomas Mortagne >Priority: Major > > commons-io is embedded in velocity-engine-core, which is OK from Java point > of view since its package is renamed (not causing any dependency problems). > The problem is that it contains the commons-io Maven descriptors at the > standard location (/META-INF/maven/commons-io/commons-io/), which is a > problem when you analyze JAR files to find what's in it because it ends up > being identified as a JAR exposing commons-io (which is not the case since > it's weaved). > Honestly, it feels very strange to embed commons-io in the first place given > that commons-lang for example is a transitive dependency, so I feel like the > simplest would just be to remove all the plumbing to embed and weave > commons-io and simply keep it as a regular transitive dependency. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-970) velocity-engine-core contains commons-io Maven descriptor
[ https://issues.apache.org/jira/browse/VELOCITY-970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17805700#comment-17805700 ] Thomas Mortagne commented on VELOCITY-970: -- bq. we should include it as a direct dependency Strangely it seems to be the case on github (https://github.com/apache/velocity-engine/blob/master/velocity-engine-core/pom.xml#L322) but it's not in the 2.3 pom deployed on Maven Central. > velocity-engine-core contains commons-io Maven descriptor > - > > Key: VELOCITY-970 > URL: https://issues.apache.org/jira/browse/VELOCITY-970 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.3 >Reporter: Thomas Mortagne >Priority: Major > > commons-io is embedded in velocity-engine-core, which is OK from Java point > of view since its package is renamed (not causing any dependency problems). > The problem is that it contains the commons-io Maven descriptors at the > standard location (/META-INF/maven/commons-io/commons-io/), which is a > problem when you analyze JAR files to find what's in it because it ends up > being identified as a JAR exposing commons-io (which is not the case since > it's weaved). > Honestly, it feels very strange to embed commons-io in the first place given > that commons-lang for example is a transitive dependency, so I feel like the > simplest would just be to remove all the plumbing to embed and weave > commons-io and simply keep it as a regular transitive dependency. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-970) velocity-engine-core contains commons-io Maven descriptor
[ https://issues.apache.org/jira/browse/VELOCITY-970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17805605#comment-17805605 ] Thomas Mortagne commented on VELOCITY-970: -- Proposal pull request on https://github.com/apache/velocity-engine/pull/37. > velocity-engine-core contains commons-io Maven descriptor > - > > Key: VELOCITY-970 > URL: https://issues.apache.org/jira/browse/VELOCITY-970 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.3 >Reporter: Thomas Mortagne >Priority: Major > > commons-io is embedded in velocity-engine-core, which is OK from Java point > of view since its package is renamed (not causing any dependency problems). > The problem is that it contains the commons-io Maven descriptors at the > standard location (/META-INF/maven/commons-io/commons-io/), which is a > problem when you analyze JAR files to find what's in it because it ends up > being identified as a JAR exposing commons-io (which is not the case since > it's weaved). > Honestly, it feels very strange to embed commons-io in the first place given > that commons-lang for example is a transitive dependency, so I feel like the > simplest would just be to remove all the plumbing to embed and weave > commons-io and simply keep it as a regular transitive dependency. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-970) velocity-engine-core contains commons-io Maven descriptor
[ https://issues.apache.org/jira/browse/VELOCITY-970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17805605#comment-17805605 ] Thomas Mortagne edited comment on VELOCITY-970 at 1/11/24 2:04 PM: --- Proposal pull request available on https://github.com/apache/velocity-engine/pull/37. was (Author: tmortagne): Proposal pull request on https://github.com/apache/velocity-engine/pull/37. > velocity-engine-core contains commons-io Maven descriptor > - > > Key: VELOCITY-970 > URL: https://issues.apache.org/jira/browse/VELOCITY-970 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.3 >Reporter: Thomas Mortagne >Priority: Major > > commons-io is embedded in velocity-engine-core, which is OK from Java point > of view since its package is renamed (not causing any dependency problems). > The problem is that it contains the commons-io Maven descriptors at the > standard location (/META-INF/maven/commons-io/commons-io/), which is a > problem when you analyze JAR files to find what's in it because it ends up > being identified as a JAR exposing commons-io (which is not the case since > it's weaved). > Honestly, it feels very strange to embed commons-io in the first place given > that commons-lang for example is a transitive dependency, so I feel like the > simplest would just be to remove all the plumbing to embed and weave > commons-io and simply keep it as a regular transitive dependency. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-970) velocity-engine-core contains commons-io Maven descriptor
[ https://issues.apache.org/jira/browse/VELOCITY-970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mortagne updated VELOCITY-970: - Description: commons-io is embedded in velocity-engine-core, which is OK from Java point of view since its package is renamed (not causing any dependency problems). The problem is that it contains the commons-io Maven descriptors at the standard location (/META-INF/maven/commons-io/commons-io/), which is a problem when you analyze JAR files to find what's in it because it ends up being identified as a JAR exposing commons-io (which is not the case since it's weaved). Honestly, it feels very strange to embed commons-io in the first place given that commons-lang for example is a transitive dependency, so I feel like the simplest would just be to remove all the plumbing to embed and weave commons-io and simply keep it as a regular transitive dependency. was: commons-io is embedded in velocity-engine-core, which is OK from Java point of view since its package is renamed (not causing any dependency problems). The problem is that it contains the commons-io Maven descriptors at the standard location (/META-INF/maven/commons-io/commons-io/), which is a problem when you analyze JAR files to find what's in it because it ends up being identified as a JAR exposing commons-io (which is not the case since it's weaved). Honestly, it feels very strange to embed commons-io in the first place given that commons-lang for example is a transitive dependency, so I feel like the simplest would just be to remove all the plumbing to embed and weave commons-io and simply keep it as transitive dependency. > velocity-engine-core contains commons-io Maven descriptor > - > > Key: VELOCITY-970 > URL: https://issues.apache.org/jira/browse/VELOCITY-970 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.3 >Reporter: Thomas Mortagne >Priority: Major > > commons-io is embedded in velocity-engine-core, which is OK from Java point > of view since its package is renamed (not causing any dependency problems). > The problem is that it contains the commons-io Maven descriptors at the > standard location (/META-INF/maven/commons-io/commons-io/), which is a > problem when you analyze JAR files to find what's in it because it ends up > being identified as a JAR exposing commons-io (which is not the case since > it's weaved). > Honestly, it feels very strange to embed commons-io in the first place given > that commons-lang for example is a transitive dependency, so I feel like the > simplest would just be to remove all the plumbing to embed and weave > commons-io and simply keep it as a regular transitive dependency. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-970) velocity-engine-core contains commons-io Maven descriptor
[ https://issues.apache.org/jira/browse/VELOCITY-970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mortagne updated VELOCITY-970: - Description: commons-io is embedded in velocity-engine-core, which is OK from Java point of view since its package is renamed (not causing any dependency problems). The problem is that it contains the commons-io Maven descriptors at the standard location (/META-INF/maven/commons-io/commons-io/), which is a problem when you analyze JAR files to find what's in it because it ends up being identified as a JAR exposing commons-io (which is not the case since it's weaved). Honestly, it feels very strange to embed commons-io in the first place given that commons-lang for example is a transitive dependency, so I feel like the simplest would just be to remove all the plumbing to embed and weave commons-io and simply keep it as transitive dependency. was: commons-io is embedded in velocity-engine-core, which is OK from Java point of view since it's weaved (not causing any dependency problems). The problem is that it contains the commons-io Maven descriptors at the standard location (/META-INF/maven/commons-io/commons-io/), which is a problem when you analyze JAR files to find what's in it because it ends up being identified as a JAR exposing commons-io (which is not the case since it's weaved). Honestly, it feels very strange to embed commons-io in the first place given that commons-lang for example is a transitive dependency, so I feel like the simplest would just be to remove all the plumbing to embed and weave commons-io and simply keep it as transitive dependency. > velocity-engine-core contains commons-io Maven descriptor > - > > Key: VELOCITY-970 > URL: https://issues.apache.org/jira/browse/VELOCITY-970 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.3 >Reporter: Thomas Mortagne >Priority: Major > > commons-io is embedded in velocity-engine-core, which is OK from Java point > of view since its package is renamed (not causing any dependency problems). > The problem is that it contains the commons-io Maven descriptors at the > standard location (/META-INF/maven/commons-io/commons-io/), which is a > problem when you analyze JAR files to find what's in it because it ends up > being identified as a JAR exposing commons-io (which is not the case since > it's weaved). > Honestly, it feels very strange to embed commons-io in the first place given > that commons-lang for example is a transitive dependency, so I feel like the > simplest would just be to remove all the plumbing to embed and weave > commons-io and simply keep it as transitive dependency. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Created] (VELOCITY-970) velocity-engine-core contains commons-io Maven descriptor
Thomas Mortagne created VELOCITY-970: Summary: velocity-engine-core contains commons-io Maven descriptor Key: VELOCITY-970 URL: https://issues.apache.org/jira/browse/VELOCITY-970 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 2.3 Reporter: Thomas Mortagne commons-io is embedded in velocity-engine-core, which is OK from Java point of view since it's weaved (not causing any dependency problems). The problem is that it contains the commons-io Maven descriptors at the standard location (/META-INF/maven/commons-io/commons-io/), which is a problem when you analyze JAR files to find what's in it because it ends up being identified as a JAR exposing commons-io (which is not the case since it's weaved). Honestly, it feels very strange to embed commons-io in the first place given that commons-lang for example is a transitive dependency, so I feel like the simplest would just be to remove all the plumbing to embed and weave commons-io and simply keep it as transitive dependency. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-968) In Java 17+, introspection fails in many cases due to permissions
[
https://issues.apache.org/jira/browse/VELOCITY-968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17772334#comment-17772334
]
Thomas Mortagne commented on VELOCITY-968:
--
Looks like a dupicate of VELOCITY-952.
> In Java 17+, introspection fails in many cases due to permissions
> -
>
> Key: VELOCITY-968
> URL: https://issues.apache.org/jira/browse/VELOCITY-968
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 1.7.x, 2.3
> Environment: Java 17
>Reporter: Christopher Schultz
>Priority: Major
>
> When running under Java 17 or later, introspection often picks an
> inaccessible method on a runtime object, which then fails when invoked.
> For example, running the example below under Java 8, the output is simple:
> {noformat}
> Cert notAfter=Wed Jan 03 12:42:32 EST 2024
> Test: Wed Jan 03 12:42:32 EST 2024
> {noformat}
> When running on Java 11 or later, we get:
> {noformat}
> Cert notAfter=Wed Jan 03 12:42:32 EST 2024
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by
> org.apache.velocity.runtime.parser.node.PropertyExecutor
> (file:.../velocity-engine-core-2.3.jar) to method
> sun.security.x509.X509CertImpl.getNotAfter()
> WARNING: Please consider reporting this to the maintainers of
> org.apache.velocity.runtime.parser.node.PropertyExecutor
> WARNING: Use --illegal-access=warn to enable warnings of further illegal
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> Test: Wed Jan 03 12:42:32 EST 2024
> {noformat}
> When running on Java 17, we get:
> {noformat}
> Cert notAfter=Wed Jan 03 12:42:32 EST 2024
> Exception in thread "main" org.apache.velocity.exception.VelocityException:
> ASTIdentifier() : exception invoking method for identifier 'notAfter' in
> class sun.security.x509.X509CertImpl
> at
> org.apache.velocity.runtime.parser.node.ASTIdentifier.execute(ASTIdentifier.java:282)
> at
> org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:368)
> at
> org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:492)
> at
> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:439)
> at org.apache.velocity.Template.merge(Template.java:358)
> at org.apache.velocity.Template.merge(Template.java:262)
> at CertTest.main(CertTest.java:52)
> Caused by: java.lang.IllegalAccessException: class
> org.apache.velocity.runtime.parser.node.PropertyExecutor cannot access class
> sun.security.x509.X509CertImpl (in module java.base) because module java.base
> does not export sun.security.x509 to unnamed module @45ad6cad
> at
> java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:392)
> at
> java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674)
> at java.base/java.lang.reflect.Method.invoke(Method.java:560)
> at
> org.apache.velocity.runtime.parser.node.PropertyExecutor.execute(PropertyExecutor.java:149)
> at
> org.apache.velocity.util.introspection.UberspectImpl$VelGetterImpl.invoke(UberspectImpl.java:722)
> at
> org.apache.velocity.runtime.parser.node.ASTIdentifier.execute(ASTIdentifier.java:217)
> ... 6 more
> {noformat}
> It looks like Velocity is picking an inconvenient class on which to base its
> method invocation.
>
> Here is the test source.
> {noformat}
> import java.io.OutputStreamWriter;
> import java.io.StringReader;
> import java.nio.charset.StandardCharsets;
> import java.security.cert.Certificate;
> import java.security.cert.X509Certificate;
> import java.security.cert.CertificateFactory;
> import org.apache.velocity.Template;
> import org.apache.velocity.VelocityContext;
> import org.apache.velocity.app.VelocityEngine;
> import org.apache.velocity.runtime.RuntimeServices;
> import org.apache.velocity.runtime.RuntimeSingleton;
> public class CertTest {
> private static final String certText = "-BEGIN CERTIFICATE-\n"
> + "MIICJTCCAaygAwIBAgIIXjahgh5+v08wCgYIKoZIzj0EAwMwaTEQMA4GA1UEBhMH\n"
> + "VW5rbm93bjEQMA4GA1UECBMHVW5rbm93bjEQMA4GA1UEBxMHVW5rbm93bjEQMA4G\n"
> + "A1UEChMHVW5rbm93bjEQMA4GA1UECxMHVW5rbm93bjENMAsGA1UEAxMEdGVzdDAe\n"
> + "Fw0yMzEwMDUxNzQyMzJaFw0yNDAxMDMxNzQyMzJaMGkxEDAOBgNVBAYTB1Vua25v\n"
> + "d24xEDAOBgNVBAgTB1Vua25vd24xEDAOBgNVBAcTB1Vua25vd24xEDAOBgNVBAoT\n"
> + "B1Vua25vd24xEDAOBgNVBAsTB1Vua25vd24xDTALBgNVBAMTBHRlc3QwdjAQBgcq\n"
> + "hkjOPQIBBgUrgQQAIgNiAARluamNquFohhtrjhN6Sq+QXVlb+/1GVHg0h10iDehm\n"
> + "msRkfPkugLIwRbLIaggzFkx66QcT4oIjhvM0Q1jM7a/9BhNUWJvZMa54M3Nh+K6P\n"
> + "fzp8tOGHe2EAHibDP1KSGHCjITAfMB0GA1UdDgQWBBSLy96Os2mUo7TiKAwRlEmq\n"
> +
[jira] [Updated] (VELOCITY-967) Allows passing a list of Template instances to Template#merge
[
https://issues.apache.org/jira/browse/VELOCITY-967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mortagne updated VELOCITY-967:
-
Description:
Instead of the list of template names.
In [XWiki|https://www.xwiki.org] it's possible to define Velocity macros in all
kind of locations (files, pages, attachment in a page, object fields, etc.),
they can include each other but more importantly you can have several Velocity
scripts in the same page (or a page which included several other pages and now
has several scripts) with one of the scripts reusing macros defined in a
previous one.
So far, it was not too much of a problem, I just kept reusing the same Template
instance:
{code}
currentTemplate.setResourceLoader(new SingletonResourceReader(script));
currentTemplate.process();
currentTemplate.merge(context, out);
{code}
repeat...
But I'm starting to work on caching compiled Velocity (i.e. {{Template}}
instances) and execute them later in various different contexts. It's not a
problem for variables since they are stored in the context, but there is still
a problem for which I don't have a clean solution: passing current macros
(gathered from previous executed templates) to the currently executed one. I
first thought I could just call VelocityContext#setMacroLibraries before
template.merge(mergeContext, out); but unfortunately, merge "breaks" the
current context (it replaces the context macro libraries by an empty list) and
using template.merge(mergeContext, out, names); and a custom ResourceManager
would add too much complexity for various use cases.
My current workaround is to pass a custom Velocity context which overwrite
setMacroLibraries and ignore any call with an empty list as parameters (yeah,
not a huge fan either).
The simplest for us would be to pass directly the macro libraries Template
instances to Template#merge (to be perfectly honest, passing just the macros is
our real need but passing a Template list is more generic and in line with what
Template#merge is already doing in practice).
My plan is to write a (very easy) pull request, but I wanted to discuss the
idea first to see how well it's received.
was:
Instead of the list of template names.
In [XWiki|https://www.xwiki.org] it's possible to define Velocity macros in all
kind of locations (files, pages, attachment in a page, object fields, etc.),
they can include each other but more importantly you can have several Velocity
scripts in the same page (or a page which included several other pages and now
has several scripts) with one of the scripts reusing macros defined in a
previous one.
So far, it was not too much of a problem, I just kept reusing the same Template
instance:
{code}
currentTemplate.setResourceLoader(new SingletonResourceReader(script));
currentTemplate.process();
currentTemplate.merge(context, out);
{code}
repeat...
But I'm starting to work on caching compiled Velocity (i.e. {{Template}}
instances) and execute them later in various different contexts. It's not a
problem for variables since they are stored in the context, but there is still
a problem for which I don't have a clean solution: passing current macros
(gathered from previous executed templates) to the currently executed one. I
first thought I could just call VelocityContext#setMacroLibraries before
template.merge(mergeContext, out); but unfortunately, merge "breaks" the
current context (it replaces the context macro libraries by an empty list) and
using template.merge(mergeContext, out, names); and a custom ResourceManager
would add too much complexity for various use cases.
My current workaround is to pass a custom Velocity context which overwrite
setMacroLibraries and ignore any call with an empty list as parameters (yeah,
not a huge fan either).
The simplest for us would be to pass directly the macro libraries Template
instances of Template#merge (to be perfectly honest, passing just the macros is
our real need but passing a Template list is more generic and in line with what
Template#merge is already doing in practice).
My plan is to write a (very easy) pull request, but I wanted to discuss the
idea first to see how well it's received.
> Allows passing a list of Template instances to Template#merge
> -
>
> Key: VELOCITY-967
> URL: https://issues.apache.org/jira/browse/VELOCITY-967
> Project: Velocity
> Issue Type: Improvement
> Components: Engine
>Affects Versions: 2.3
>Reporter: Thomas Mortagne
>Priority: Major
>
> Instead of the list of template names.
> In [XWiki|https://www.xwiki.org] it's possible to define Velocity macros in
> all kind of locations (files, pages, attachment in a page, object fields,
> etc.), they can include each other but more importantly you can have
[jira] [Updated] (VELOCITY-967) Allows passing a list of Template instances to Template#merge
[
https://issues.apache.org/jira/browse/VELOCITY-967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mortagne updated VELOCITY-967:
-
Description:
Instead of the list of template names.
In [XWiki|https://www.xwiki.org] it's possible to define Velocity macros in all
kind of locations (files, pages, attachment in a page, object fields, etc.),
they can include each other but more importantly you can have several Velocity
scripts in the same page (or a page which included several other pages and now
has several scripts) with one of the scripts reusing macros defined in a
previous one.
So far, it was not too much of a problem, I just kept reusing the same Template
instance:
{code}
currentTemplate.setResourceLoader(new SingletonResourceReader(script));
currentTemplate.process();
currentTemplate.merge(context, out);
{code}
repeat...
But I'm starting to work on caching compiled Velocity (i.e. {{Template}}
instances) and execute them later in various different contexts. It's not a
problem for variables since they are stored in the context, but there is still
a problem for which I don't have a clean solution: passing current macros
(gathered from previous executed templates) to the currently executed one. I
first thought I could just call VelocityContext#setMacroLibraries before
template.merge(mergeContext, out); but unfortunately, merge "breaks" the
current context (it replaces the context macro libraries by an empty list) and
using template.merge(mergeContext, out, names); and a custom ResourceManager
would add too much complexity for various use cases.
My current workaround is to pass a custom Velocity context which overwrite
setMacroLibraries and ignore any call with an empty list as parameters (yeah,
not a huge fan either).
The simplest for us would be to pass directly the macro libraries Template
instances of Template#merge (to be perfectly honest, passing just the macros is
our real need but passing a Template list is more generic and in line with what
Template#merge is already doing in practice).
My plan is to write a (very easy) pull request, but I wanted to discuss the
idea first to see how well it's received.
was:
Instead of the list of template names.
In [XWiki|https://www.xwiki.org] it's possible to define Velocity macros in all
kind of locations (files, pages, attachment in a page, object fields, etc.),
they can include each other but more importantly you can have several Velocity
scripts in the same page (or a page which included several other pages and now
has several scripts) with one of the scripts reusing macros defined in a
previous one.
So far, it was not too much of a problem, I just kept reusing the same Template
instance:
{{code}}
currentTemplate.setResourceLoader(new SingletonResourceReader(script));
currentTemplate.process();
currentTemplate.merge(context, out);
{{code}}
repeat...
But I'm starting to work on caching compiled Velocity (i.e. {{Template}}
instances) and execute them later in various different contexts. It's not a
problem for variables since they are stored in the context, but there is still
a problem for which I don't have a clean solution: passing current macros
(gathered from previous executed templates) to the currently executed one. I
first thought I could just call VelocityContext#setMacroLibraries before
template.merge(mergeContext, out); but unfortunately, merge "breaks" the
current context (it replaces the context macro libraries by an empty list) and
using template.merge(mergeContext, out, names); and a custom ResourceManager
would add too much complexity for various use cases.
My current workaround is to pass a custom Velocity context which overwrite
setMacroLibraries and ignore any call with an empty list as parameters (yeah,
not a huge fan either).
The simplest for us would be to pass directly the macro libraries Template
instances of Template#merge (to be perfectly honest, passing just the macros is
our real need but passing a Template list is more generic and in line with what
Template#merge is already doing in practice).
My plan is to write a (very easy) pull request, but I wanted to discuss the
idea first to see how well it's received.
> Allows passing a list of Template instances to Template#merge
> -
>
> Key: VELOCITY-967
> URL: https://issues.apache.org/jira/browse/VELOCITY-967
> Project: Velocity
> Issue Type: Improvement
> Components: Engine
>Affects Versions: 2.3
>Reporter: Thomas Mortagne
>Priority: Major
>
> Instead of the list of template names.
> In [XWiki|https://www.xwiki.org] it's possible to define Velocity macros in
> all kind of locations (files, pages, attachment in a page, object fields,
> etc.), they can include each other but more importantly you can
[jira] [Created] (VELOCITY-967) Allows passing a list of Template instances to Template#merge
Thomas Mortagne created VELOCITY-967:
Summary: Allows passing a list of Template instances to
Template#merge
Key: VELOCITY-967
URL: https://issues.apache.org/jira/browse/VELOCITY-967
Project: Velocity
Issue Type: Improvement
Components: Engine
Affects Versions: 2.3
Reporter: Thomas Mortagne
Instead of the list of template names.
In [XWiki|https://www.xwiki.org] it's possible to define Velocity macros in all
kind of locations (files, pages, attachment in a page, object fields, etc.),
they can include each other but more importantly you can have several Velocity
scripts in the same page (or a page which included several other pages and now
has several scripts) with one of the scripts reusing macros defined in a
previous one.
So far, it was not too much of a problem, I just kept reusing the same Template
instance:
{{code}}
currentTemplate.setResourceLoader(new SingletonResourceReader(script));
currentTemplate.process();
currentTemplate.merge(context, out);
{{code}}
repeat...
But I'm starting to work on caching compiled Velocity (i.e. {{Template}}
instances) and execute them later in various different contexts. It's not a
problem for variables since they are stored in the context, but there is still
a problem for which I don't have a clean solution: passing current macros
(gathered from previous executed templates) to the currently executed one. I
first thought I could just call VelocityContext#setMacroLibraries before
template.merge(mergeContext, out); but unfortunately, merge "breaks" the
current context (it replaces the context macro libraries by an empty list) and
using template.merge(mergeContext, out, names); and a custom ResourceManager
would add too much complexity for various use cases.
My current workaround is to pass a custom Velocity context which overwrite
setMacroLibraries and ignore any call with an empty list as parameters (yeah,
not a huge fan either).
The simplest for us would be to pass directly the macro libraries Template
instances of Template#merge (to be perfectly honest, passing just the macros is
our real need but passing a Template list is more generic and in line with what
Template#merge is already doing in practice).
My plan is to write a (very easy) pull request, but I wanted to discuss the
idea first to see how well it's received.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-952) Velocity is calling the "wrong" method
[
https://issues.apache.org/jira/browse/VELOCITY-952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17711273#comment-17711273
]
Thomas Mortagne commented on VELOCITY-952:
--
bq. an uberspector on XWiki side
Implemented on
https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodOverrideUberspector.java
> Velocity is calling the "wrong" method
> --
>
> Key: VELOCITY-952
> URL: https://issues.apache.org/jira/browse/VELOCITY-952
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Thomas Mortagne
>Priority: Major
>
> OK, the title is maybe a bit harsh, but it catches the eyes :)
> At XWiki we recently started testing on Java 17 to see if there is any
> problem which leaded us to add things like {{--add-opens
> java.base/java.util=ALL-UNNAMED}} but Velocity happen to be the source of
> another problem related to the new module world.
> When doing something like {{$datetool.timeZone.getOffset(0)}} ($datetool
> being the org.apache.velocity.tools.generic.DateTool) we get the following
> error:
> {noformat}
> ...
> Caused by: java.lang.IllegalAccessException: class
> org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl cannot
> access class sun.util.calendar.ZoneInfo (in module java.base) because module
> java.base does not export sun.util.calendar to unnamed module @7ca16adc
> at
> java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:392)
> at
> java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674)
> at java.base/java.lang.reflect.Method.invoke(Method.java:560)
> at
> org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:571)
> at
> org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:554)
> at
> org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:221)
> ... 199 more
> {noformat}
> The reason is that while the developer intent/expectation was to call
> "java.util.TimeZone#getOffset(0)" what Velocity really called from JVM point
> of view is "sun.util.calendar.ZoneInfo.getOffset(0)" directly.
> That's because Velocity is doing (I assume, since I did not check the exact
> code) the equivalent of:
> {noformat}
> java.util.TimeZone.getDefault().getClass().getMethod("getOffset",
> long.class).invoke(TimeZone.getDefault(), 0);
> {noformat}
> which is itself the equivalent of:
> {noformat}
> sun.util.calendar.ZoneInfo.class.getMethod("getOffset",
> long.class).invoke(TimeZone.getDefault(), 0);
> {noformat}
> I guess the only way to fix this would be to track down the lowest overridden
> Method (I agree, it might not always be easy to choose between two interfaces
> declaring a method with the same signature, but choosing the first one we
> find from the same hierarchy level is still better than nothing) and call
> that one instead. With the use case used as example in this issue, that would
> mean ending up doing the equivalent of:
> {noformat}
> java.util.TimeZone.class.getMethod("getOffset",
> long.class).invoke(TimeZone.getDefault(), 0);
> {noformat}
> which, from JVM point of view, is covered by the {{--add-opens
> java.base/java.util=ALL-UNNAMED}}.
> It would be a big change, but at least can't think of any retro-compatibility
> problem it might cause.
> One might be tempted to answer "just add {{--add-opens
> java.base/sun.util.calendar=ALL-UNNAMED}}" but it does not seem fair as this
> is not what the API that the script uses was exposing at all, you might need
> to document a different one for each JVM implementation (even if it's
> probably unlikely for this specific example) but more importantly you will
> potentially need quite a lot of those and will only discover it at runtime
> since it's not so easy to guess from an API in which you only know the public
> JVM classes since that's what you manipulate.
> I would be happy to work on this, but I wanted first ask what others think
> about this problem in general and the possible solutions I may have missed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-952) Velocity is calling the "wrong" method
[
https://issues.apache.org/jira/browse/VELOCITY-952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17710993#comment-17710993
]
Thomas Mortagne commented on VELOCITY-952:
--
{quote}
bq. respecting the method return type
Carrying this information around with the object sounds like a complex thing to
change (but maybe not, I don't know the Velocity AST very well), but I agree
it's probably the most accurate.
{quote}
So I finally did some digging on what it would take to implement this idea, and
it's indeed not trivial. From what I understood, the problem is that here is no
way to associate metadata to a value in the context right now, so all the APIs
which manipulate the value of a variable don't have any way to pass/return more
info about this value (thinking especially about associating a Type with the
value in the Context and how to return a Type along with the value returned by
ASTMethod#execute.
I started by refactoring a bit {{org.apache.velocity.context.Context}} to
support associating metadata to an entry without breaking existing API, but
then the number of things to change in pretty critical places to take this into
account is a bit overwhelming for me and a huge challenge in terms of retro
compatibly without really knowing if that's really the direction that you guys
want to take.
Problem is that this bug makes pretty much impossible to say that XWiki
supports Java 17 because of the many unforeseen IllegalAccessException failures
you can end up with depending on which apparently standard Java API you are
manipulating in a script. So for now my plan is to workaround this with an
uberspector on XWiki side doing what I initially proposed: try to find the
lowest overwritten Method (which, I agree, is not the best and not something I
would recommend on standard Velocity side compared to the "carry the return
type around with the value" idea).
> Velocity is calling the "wrong" method
> --
>
> Key: VELOCITY-952
> URL: https://issues.apache.org/jira/browse/VELOCITY-952
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Thomas Mortagne
>Priority: Major
>
> OK, the title is maybe a bit harsh, but it catches the eyes :)
> At XWiki we recently started testing on Java 17 to see if there is any
> problem which leaded us to add things like {{--add-opens
> java.base/java.util=ALL-UNNAMED}} but Velocity happen to be the source of
> another problem related to the new module world.
> When doing something like {{$datetool.timeZone.getOffset(0)}} ($datetool
> being the org.apache.velocity.tools.generic.DateTool) we get the following
> error:
> {noformat}
> ...
> Caused by: java.lang.IllegalAccessException: class
> org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl cannot
> access class sun.util.calendar.ZoneInfo (in module java.base) because module
> java.base does not export sun.util.calendar to unnamed module @7ca16adc
> at
> java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:392)
> at
> java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674)
> at java.base/java.lang.reflect.Method.invoke(Method.java:560)
> at
> org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:571)
> at
> org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:554)
> at
> org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:221)
> ... 199 more
> {noformat}
> The reason is that while the developer intent/expectation was to call
> "java.util.TimeZone#getOffset(0)" what Velocity really called from JVM point
> of view is "sun.util.calendar.ZoneInfo.getOffset(0)" directly.
> That's because Velocity is doing (I assume, since I did not check the exact
> code) the equivalent of:
> {noformat}
> java.util.TimeZone.getDefault().getClass().getMethod("getOffset",
> long.class).invoke(TimeZone.getDefault(), 0);
> {noformat}
> which is itself the equivalent of:
> {noformat}
> sun.util.calendar.ZoneInfo.class.getMethod("getOffset",
> long.class).invoke(TimeZone.getDefault(), 0);
> {noformat}
> I guess the only way to fix this would be to track down the lowest overridden
> Method (I agree, it might not always be easy to choose between two interfaces
> declaring a method with the same signature, but choosing the first one we
> find from the same hierarchy level is still better than nothing) and call
> that one instead. With the use case used as example in this issue, that would
> mean ending up doing the equivalent of:
> {noformat}
> java.util.TimeZone.class.getMethod("getOffset",
> long.class).invoke(TimeZone.getDefault(), 0);
> {noformat}
> which, from JVM point of view, is covered by the
[jira] [Updated] (VELOCITY-952) Velocity is calling the "wrong" method
[
https://issues.apache.org/jira/browse/VELOCITY-952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mortagne updated VELOCITY-952:
-
Description:
OK, the title is maybe a bit harsh, but it catches the eyes :)
At XWiki we recently started testing on Java 17 to see if there is any problem
which leaded us to add things like {{--add-opens
java.base/java.util=ALL-UNNAMED}} but Velocity happen to be the source of
another problem related to the new module world.
When doing something like {{$datetool.timeZone.getOffset(0)}} ($datetool being
the org.apache.velocity.tools.generic.DateTool) we get the following error:
{noformat}
...
Caused by: java.lang.IllegalAccessException: class
org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl cannot
access class sun.util.calendar.ZoneInfo (in module java.base) because module
java.base does not export sun.util.calendar to unnamed module @7ca16adc
at
java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:392)
at
java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674)
at java.base/java.lang.reflect.Method.invoke(Method.java:560)
at
org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:571)
at
org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:554)
at
org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:221)
... 199 more
{noformat}
The reason is that while the developer intent/expectation was to call
"java.util.TimeZone#getOffset(0)" what Velocity really called from JVM point of
view is "sun.util.calendar.ZoneInfo.getOffset(0)" directly.
That's because Velocity is doing (I assume, since I did not check the exact
code) the equivalent of:
{noformat}
java.util.TimeZone.getDefault().getClass().getMethod("getOffset",
long.class).invoke(TimeZone.getDefault(), 0);
{noformat}
which is itself the equivalent of:
{noformat}
sun.util.calendar.ZoneInfo.class.getMethod("getOffset",
long.class).invoke(TimeZone.getDefault(), 0);
{noformat}
I guess the only way to fix this would be to track down the lowest overridden
Method (I agree, it might not always be easy to choose between two interfaces
declaring a method with the same signature, but choosing the first one we find
from the same hierarchy level is still better than nothing) and call that one
instead. With the use case used as example in this issue, that would mean
ending up doing the equivalent of:
{noformat}
java.util.TimeZone.class.getMethod("getOffset",
long.class).invoke(TimeZone.getDefault(), 0);
{noformat}
which, from JVM point of view, is covered by the {{--add-opens
java.base/java.util=ALL-UNNAMED}}.
It would be a big change, but at least can't think of any retro-compatibility
problem it might cause.
One might be tempted to answer "just add {{--add-opens
java.base/sun.util.calendar=ALL-UNNAMED}}" but it does not seem fair as this is
not what the API that the script uses was exposing at all, you might need to
document a different one for each JVM implementation (even if it's probably
unlikely for this specific example) but more importantly you will potentially
need quite a lot of those and will only discover it at runtime since it's not
so easy to guess from an API in which you only know the public JVM classes
since that's what you manipulate.
I would be happy to work on this, but I wanted first ask what others think
about this problem in general and the possible solutions I may have missed.
was:
OK, the title is maybe a bit harsh, but it catches the eyes :)
At XWiki we recently started testing on Java 17 to see if there is any problem
which leaded us to add things like {{--add-opens
java.base/java.util=ALL-UNNAMED}} but Velocity happen to be the source of
another problem related to the new module world.
When doing something like {{$datetool.timeZone.getOffset(0)}} ($datetool being
the org.apache.velocity.tools.generic.DateTool) we get the following error:
{noformat}
...
Caused by: java.lang.IllegalAccessException: class
org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl cannot
access class sun.util.calendar.ZoneInfo (in module java.base) because module
java.base does not export sun.util.calendar to unnamed module @7ca16adc
at
java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:392)
at
java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674)
at java.base/java.lang.reflect.Method.invoke(Method.java:560)
at
org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:571)
at
org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:554)
at
org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:221)
... 199 more
{noformat}
The reason is that while
[jira] [Commented] (VELOCITY-952) Velocity is calling the "wrong" method
[
https://issues.apache.org/jira/browse/VELOCITY-952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17504830#comment-17504830
]
Thomas Mortagne commented on VELOCITY-952:
--
bq. respecting the method return type
Carrying this information around with the object sounds like a complex thing to
change (but maybe not, I don't know the Velocity AST very well), but I agree
it's probably the most accurate.
> Velocity is calling the "wrong" method
> --
>
> Key: VELOCITY-952
> URL: https://issues.apache.org/jira/browse/VELOCITY-952
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Thomas Mortagne
>Priority: Major
>
> OK, the title is maybe a bit harsh, but it catches the eyes :)
> At XWiki we recently started testing on Java 17 to see if there is any
> problem which leaded us to add things like {{--add-opens
> java.base/java.util=ALL-UNNAMED}} but Velocity happen to be the source of
> another problem related to the new module world.
> When doing something like {{$datetool.timeZone.getOffset(0)}} ($datetool
> being the org.apache.velocity.tools.generic.DateTool) we get the following
> error:
> {noformat}
> ...
> Caused by: java.lang.IllegalAccessException: class
> org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl cannot
> access class sun.util.calendar.ZoneInfo (in module java.base) because module
> java.base does not export sun.util.calendar to unnamed module @7ca16adc
> at
> java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:392)
> at
> java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674)
> at java.base/java.lang.reflect.Method.invoke(Method.java:560)
> at
> org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:571)
> at
> org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:554)
> at
> org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:221)
> ... 199 more
> {noformat}
> The reason is that while the developer intent/expectation was to call
> "java.util.TimeZone#getOffset(0)" what Velocity really called from JVM point
> of view is "sun.util.calendar.ZoneInfo.getOffset(0)" directly.
> That's because Velocity is doing (I assume, since I did not check the exact
> code) the equivalent of:
> {{noformat}}
> java.util.TimeZone.getDefault().getClass().getMethod("getOffset",
> long.class).invoke(TimeZone.getDefault(), 0);
> {{noformat}}
> which is itself the equivalent of:
> {{noformat}}
> sun.util.calendar.ZoneInfo.class.getMethod("getOffset",
> long.class).invoke(TimeZone.getDefault(), 0);
> {{noformat}}
> I guess the only way to fix this would be to track down the lowest overridden
> Method (I agree, it might not always be easy to choose between two interfaces
> declaring a method with the same signature, but choosing the first one we
> find from the same hierarchy level is still better than nothing) and call
> that one instead. With the use case used as example in this issue, that would
> mean ending up doing the equivalent of:
> {{noformat}}
> java.util.TimeZone.class.getMethod("getOffset",
> long.class).invoke(TimeZone.getDefault(), 0);
> {{noformat}}
> which, from JVM point of view, is covered by the {{--add-opens
> java.base/java.util=ALL-UNNAMED}}.
> It would be a big change, but at least can't think of any retro-compatibility
> problem it might cause.
> One might be tempted to answer "just add {{--add-opens
> java.base/sun.util.calendar=ALL-UNNAMED}}" but it does not seem fair as this
> is not what the API that the script uses was exposing at all, you might need
> to document a different one for each JVM implementation (even if it's
> probably unlikely for this specific example) but more importantly you will
> potentially need quite a lot of those and will only discover it at runtime
> since it's not so easy to guess from an API in which you only know the public
> JVM classes since that's what you manipulate.
> I would be happy to work on this, but I wanted first ask what others think
> about this problem in general and the possible solutions I may have missed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-952) Velocity is calling the "wrong" Method
[
https://issues.apache.org/jira/browse/VELOCITY-952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mortagne updated VELOCITY-952:
-
Description:
OK, the title is maybe a bit harsh, but it catches the eyes :)
At XWiki we recently started testing on Java 17 to see if there is any problem
which leaded us to add things like {{--add-opens
java.base/java.util=ALL-UNNAMED}} but Velocity happen to be the source of
another problem related to the new module world.
When doing something like {{$datetool.timeZone.getOffset(0)}} ($datetool being
the org.apache.velocity.tools.generic.DateTool) we get the following error:
{noformat}
...
Caused by: java.lang.IllegalAccessException: class
org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl cannot
access class sun.util.calendar.ZoneInfo (in module java.base) because module
java.base does not export sun.util.calendar to unnamed module @7ca16adc
at
java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:392)
at
java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674)
at java.base/java.lang.reflect.Method.invoke(Method.java:560)
at
org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:571)
at
org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:554)
at
org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:221)
... 199 more
{noformat}
The reason is that while the developer intent/expectation was to call
"java.util.TimeZone#getOffset(0)" what Velocity really called from JVM point of
view is "sun.util.calendar.ZoneInfo.getOffset(0)" directly.
That's because Velocity is doing (I assume, since I did not check the exact
code) the equivalent of:
{{noformat}}
java.util.TimeZone.getDefault().getClass().getMethod("getOffset",
long.class).invoke(TimeZone.getDefault(), 0);
{{noformat}}
which is itself the equivalent of:
{{noformat}}
sun.util.calendar.ZoneInfo.class.getMethod("getOffset",
long.class).invoke(TimeZone.getDefault(), 0);
{{noformat}}
I guess the only way to fix this would be to track down the lowest overridden
Method (I agree, it might not always be easy to choose between two interfaces
declaring a method with the same signature, but choosing the first one we find
from the same hierarchy level is still better than nothing) and call that one
instead. With the use case used as example in this issue, that would mean
ending up doing the equivalent of:
{{noformat}}
java.util.TimeZone.class.getMethod("getOffset",
long.class).invoke(TimeZone.getDefault(), 0);
{{noformat}}
which, from JVM point of view, is covered by the {{--add-opens
java.base/java.util=ALL-UNNAMED}}.
It would be a big change, but at least can't think of any retro-compatibility
problem it might cause.
One might be tempted to answer "just add {{--add-opens
java.base/sun.util.calendar=ALL-UNNAMED}}" but it does not seem fair as this is
not what the API that the script uses was exposing at all, you might need to
document a different one for each JVM implementation (even if it's probably
unlikely for this specific example) but more importantly you will potentially
need quite a lot of those and will only discover it at runtime since it's not
so easy to guess from an API in which you only know the public JVM classes
since that's what you manipulate.
I would be happy to work on this, but I wanted first ask what others think
about this problem in general and the possible solutions I may have missed.
was:
OK, the title is maybe a bit harsh, but it catches the eyes :)
At XWiki we recently started testing on Java 17 to see if there is any problem
which leaded us to add things like {{--add-opens
java.base/java.util=ALL-UNNAMED}} but Velocity happen to be the source of
another problem related to the new module world.
When doing something like {{$datetool.timeZone.getOffset(0)}} ($datetool being
the org.apache.velocity.tools.generic.DateTool) we get the following error:
{noformat}
...
Caused by: java.lang.IllegalAccessException: class
org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl cannot
access class sun.util.calendar.ZoneInfo (in module java.base) because module
java.base does not export sun.util.calendar to unnamed module @7ca16adc
at
java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:392)
at
java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674)
at java.base/java.lang.reflect.Method.invoke(Method.java:560)
at
org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:571)
at
org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:554)
at
org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:221)
... 199 more
{noformat}
The reason is
[jira] [Created] (VELOCITY-952) Velocity is calling the "wrong" Method
Thomas Mortagne created VELOCITY-952:
Summary: Velocity is calling the "wrong" Method
Key: VELOCITY-952
URL: https://issues.apache.org/jira/browse/VELOCITY-952
Project: Velocity
Issue Type: Bug
Components: Engine
Affects Versions: 2.3
Reporter: Thomas Mortagne
OK, the title is maybe a bit harsh, but it catches the eyes :)
At XWiki we recently started testing on Java 17 to see if there is any problem
which leaded us to add things like {{--add-opens
java.base/java.util=ALL-UNNAMED}} but Velocity happen to be the source of
another problem related to the new module world.
When doing something like {{$datetool.timeZone.getOffset(0)}} ($datetool being
the org.apache.velocity.tools.generic.DateTool) we get the following error:
{noformat}
...
Caused by: java.lang.IllegalAccessException: class
org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl cannot
access class sun.util.calendar.ZoneInfo (in module java.base) because module
java.base does not export sun.util.calendar to unnamed module @7ca16adc
at
java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:392)
at
java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674)
at java.base/java.lang.reflect.Method.invoke(Method.java:560)
at
org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:571)
at
org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:554)
at
org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:221)
... 199 more
{noformat}
The reason is that while the developer intent/expectation was to call
"java.util.TimeZone#getOffset(0)" what Velocity really called from JVM point of
view is "sun.util.calendar.ZoneInfo.getOffset(0)" directly.
That's because Velocity is doing (I assume, since I did not check the exact
code) the equivalent of:
{{noformat}}
java.util.TimeZone.getDefault().getClass().getMethod("getOffset",
long.class).invoke(TimeZone.getDefault(), 0);
{{noformat}}
which is itself the equivalent of:
{{noformat}}
sun.util.calendar.ZoneInfo.class.getMethod("getOffset",
long.class).invoke(TimeZone.getDefault(), 0);
{{noformat}}
I guess the only way to fix this would be to track down the lowest overridden
Method (I agree, it might not always be easy to choose between two interfaces
declaring a method with the same signature, but choosing the first one we find
from the same hierarchy level is still better than nothing) and call that one
instead. With the use case used as example in this issue, that would mean
ending up doing the equivalent of:
{{noformat}}
java.util.TimeZone.class.getMethod("getOffset",
long.class).invoke(TimeZone.getDefault(), 0);
{{noformat}}
which, from JVM point of view, is covered by the {{--add-opens
java.base/java.util=ALL-UNNAMED}}.
It would be a big change, but at least can't think of any retro-compatibility
problem it might cause.
One might be tempted to answer "just add {{--add-opens
java.base/sun.util.calendar=ALL-UNNAMED}}" but it does not seem fair as this is
not what the API that the script uses was exposing at all, you might need to
document a different one for each JVM implementation (even if it's probably
unlikely for this specific example) but more importantly you will potentially
need quite a lot of those and will only discover it at runtime since it's not
so easy to guess from an API in which you only know the public JVM classes
since that's what you manipulate.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-945) Error Configuring Velocity
[ https://issues.apache.org/jira/browse/VELOCITY-945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17353005#comment-17353005 ] Thomas Mortagne commented on VELOCITY-945: -- [~prs725] it feels like you should ask on Wildfly side since it seems to be a problem in the way Wildfly uses Velocity, we can hardly help you here if you don't give more Velocity related information. > Error Configuring Velocity > --- > > Key: VELOCITY-945 > URL: https://issues.apache.org/jira/browse/VELOCITY-945 > Project: Velocity > Issue Type: Task > Components: Engine >Affects Versions: 2.3 > Environment: Software platform >Reporter: Pooja >Priority: Major > > When upgrading Wildfly Server to 20, we get a error configuring velocity > error every second build. The error does not occur on the first build or if > the subsequent builds have code changes. But if deploying multiple times, the > error occurs intermittently. > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-929) Improper SLF4J dependency
[
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
[jira] [Commented] (VELOCITY-929) Improper SLF4J dependency
[
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] [Commented] (VELOCITY-926) Regression: Macro arguments names cannot collide with external references names
[
https://issues.apache.org/jira/browse/VELOCITY-926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17025402#comment-17025402
]
Thomas Mortagne commented on VELOCITY-926:
--
bq. We'll know more about kind of expected but not directly tested ones after
all XWiki integration tests are executed in a couple of hours.
Looks OK on that front too from what we can see. Well done :)
> Regression: Macro arguments names cannot collide with external references
> names
> ---
>
> Key: VELOCITY-926
> URL: https://issues.apache.org/jira/browse/VELOCITY-926
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.0, 2.1
>Reporter: Claude Brisson
>Assignee: Claude Brisson
>Priority: Major
> Fix For: 2.2
>
>
> Consider the following example:
> {code}
> #macro( test $foo $bar )
> $foo $bar
> #end
> #set($foo = 'foo')
> #set($bar = 'bar')
> #test( $bar, $foo )
> {code}
> The expected result would be "{{bar foo}}", but since 2.0 we get the
> incorrect result "{{bar bar}}", as if the first inner {{$foo}} macro argument
> was overwritting the second argument evaluation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-926) Regression: Macro arguments names cannot collide with external references names
[
https://issues.apache.org/jira/browse/VELOCITY-926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [Comment Edited] (VELOCITY-926) Regression: Macro arguments names cannot collide with external references names
[
https://issues.apache.org/jira/browse/VELOCITY-926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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
[
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
[
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] [Comment Edited] (VELOCITY-926) Regression: Macro arguments names cannot collide with external references names
[
https://issues.apache.org/jira/browse/VELOCITY-926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024342#comment-17024342
]
Thomas Mortagne edited comment on VELOCITY-926 at 1/27/20 1:46 PM:
---
bq. That's why I was asking for a specific use case
What I can tell you is that we did fixed several codes in XWiki Standard doing
that but I agree with you that it was mistakes in both cases. So yes I don't
have a strong use case to describe but any weird behavior always end up being
expected and used in 10 years :) From what I understand the reason for this
behavior in 1.7 is a side effect of the local macro context (the macro
parameter being null the local context but variables were also fallbacking to
global context when unset) which does not exist anymore and I guess it not
really easy to get back this behavior without getting back the local macro
context which you said you did not wanted anymore even as a retro compatible
option.
was (Author: tmortagne):
bq. That's why I was asking for a specific use case
What I can tell you is that we did fixed several codes in XWiki Standard doing
that but I agree with you that it was mistakes in both cases. So yes I don't
have a strong use case to describe but any weird behavior always end up being
expected and used in 10 years :) From what I understand the reason for this
behavior in 1.7 is a side effect of the local macro context (the macro
parameter being unset in the local context but variables were also fallbacking
to global context when unset) which does not exist anymore and I guess it not
really easy to get back this behavior without getting back the local macro
context which you said you did not wanted anymore even as a retro compatible
option.
> Regression: Macro arguments names cannot collide with external references
> names
> ---
>
> Key: VELOCITY-926
> URL: https://issues.apache.org/jira/browse/VELOCITY-926
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.0, 2.1
>Reporter: Claude Brisson
>Assignee: Claude Brisson
>Priority: Major
> Fix For: 2.2
>
>
> Consider the following example:
> {code}
> #macro( test $foo $bar )
> $foo $bar
> #end
> #set($foo = 'foo')
> #set($bar = 'bar')
> #test( $bar, $foo )
> {code}
> The expected result would be "{{bar foo}}", but since 2.0 we get the
> incorrect result "{{bar bar}}", as if the first inner {{$foo}} macro argument
> was overwritting the second argument evaluation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-926) Regression: Macro arguments names cannot collide with external references names
[
https://issues.apache.org/jira/browse/VELOCITY-926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024342#comment-17024342
]
Thomas Mortagne edited comment on VELOCITY-926 at 1/27/20 1:39 PM:
---
bq. That's why I was asking for a specific use case
What I can tell you is that we did fixed several codes in XWiki Standard doing
that but I agree with you that it was mistakes in both cases. So yes I don't
have a strong use case to describe but any weird behavior always end up being
expected and used in 10 years :) From what I understand the reason for this
behavior in 1.7 is a side effect of the local macro context (the macro
parameter being unset in the local context but variables were also fallbacking
to global context when unset) which does not exist anymore and I guess it not
really easy to get back this behavior without getting back the local macro
context which you said you did not wanted anymore even as a retro compatible
option.
was (Author: tmortagne):
bq. That's why I was asking for a specific use case
What I can tell you is that we did fixed several codes in XWiki Standard doing
that but I agree with you that it was mistakes in both cases. So yes I don't
have a strong use case to describe but any weird behavior always end up being
expected and used in 10 years :) From what I understand the reason for this
behavior in 1.7 is a side effect of the local macro context which does not
exist anymore and I guess it not really easy to get back this behavior without
getting back the local macro context which you said you did not wanted anymore
even as a retro compatible option.
> Regression: Macro arguments names cannot collide with external references
> names
> ---
>
> Key: VELOCITY-926
> URL: https://issues.apache.org/jira/browse/VELOCITY-926
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.0, 2.1
>Reporter: Claude Brisson
>Assignee: Claude Brisson
>Priority: Major
> Fix For: 2.2
>
>
> Consider the following example:
> {code}
> #macro( test $foo $bar )
> $foo $bar
> #end
> #set($foo = 'foo')
> #set($bar = 'bar')
> #test( $bar, $foo )
> {code}
> The expected result would be "{{bar foo}}", but since 2.0 we get the
> incorrect result "{{bar bar}}", as if the first inner {{$foo}} macro argument
> was overwritting the second argument evaluation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-926) Regression: Macro arguments names cannot collide with external references names
[
https://issues.apache.org/jira/browse/VELOCITY-926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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-926) Regression: Macro arguments names cannot collide with external references names
[
https://issues.apache.org/jira/browse/VELOCITY-926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024342#comment-17024342
]
Thomas Mortagne commented on VELOCITY-926:
--
bq. That's why I was asking for a specific use case
What I can tell you is that we did fixed several codes in XWiki Standard doing
that but I agree with you that it was mistakes in both cases. So yes I don't
have a strong use case to describe but any weird behavior always end up being
expected and used in 10 years :)
> Regression: Macro arguments names cannot collide with external references
> names
> ---
>
> Key: VELOCITY-926
> URL: https://issues.apache.org/jira/browse/VELOCITY-926
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.0, 2.1
>Reporter: Claude Brisson
>Assignee: Claude Brisson
>Priority: Major
> Fix For: 2.2
>
>
> Consider the following example:
> {code}
> #macro( test $foo $bar )
> $foo $bar
> #end
> #set($foo = 'foo')
> #set($bar = 'bar')
> #test( $bar, $foo )
> {code}
> The expected result would be "{{bar foo}}", but since 2.0 we get the
> incorrect result "{{bar bar}}", as if the first inner {{$foo}} macro argument
> was overwritting the second argument evaluation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-926) Regression: Macro arguments names cannot collide with external references names
[
https://issues.apache.org/jira/browse/VELOCITY-926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [Comment Edited] (VELOCITY-926) Regression: Macro arguments names cannot collide with external references names
[
https://issues.apache.org/jira/browse/VELOCITY-926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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-925) Macro calls without parenthesis now "eats" the following newline
[
https://issues.apache.org/jira/browse/VELOCITY-925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17022747#comment-17022747
]
Thomas Mortagne commented on VELOCITY-925:
--
bq. Commit 1873088 fixes the behavior under the parser.space_gobbling=bc mode.
OK thanks. I indeed forgot to mention I'm using bc space gobbling.
> Macro calls without parenthesis now "eats" the following newline
>
>
> Key: VELOCITY-925
> URL: https://issues.apache.org/jira/browse/VELOCITY-925
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.1
>Reporter: Thomas Mortagne
>Assignee: Claude Brisson
>Priority: Major
> Fix For: 2.2
>
>
> The behavior of macro calls without parenthesis changed in 2.x. I cannot find
> anything in the changelog about that but maybe I missed it.
> The following:
> {code}
> #macro(mymacro)value#end
> #mymacro
> {code}
> produces:
> * in Velocity 1.7: "value/n"
> * in Velocity 2.x: "value"
> but:
> {code}
> #macro(mymacro)value#end
> #mymacro()
> {code}
> produces in both Velocity versions "value" (eats the newline)
> Looks like omitting parenthesis in Velocity 1.7 was making the macro call
> "inline" while having them was eating the following newline like things like
> #set directive do.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-926) Regression: Macro arguments names cannot collide with external references names
[
https://issues.apache.org/jira/browse/VELOCITY-926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [Created] (VELOCITY-925) Macro calls without parenthesis now "eats" the following newline
Thomas Mortagne created VELOCITY-925:
Summary: Macro calls without parenthesis now "eats" the following
newline
Key: VELOCITY-925
URL: https://issues.apache.org/jira/browse/VELOCITY-925
Project: Velocity
Issue Type: Bug
Components: Engine
Affects Versions: 2.1
Reporter: Thomas Mortagne
The behavior of macro calls without parenthesis changed in 2.x. I cannot find
anything in the changelog about that but maybe I missed it.
The following:
{code}
#macro(mymacro)value#end
#mymacro
{code}
produces:
* in Velocity 1.7: "value/n"
* in Velocity 2.x: "value"
but:
{code}
#macro(mymacro)value#end
#mymacro()
{code}
produces in both Velocity versions "value" (eats the newline)
Looks like omitting parenthesis in Velocity 1.7 was making the macro call
"inline" while having them was eating the following newline like things like
#set directive do.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-904) Add a flag for better backward compatibility with null macro arguments
[
https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [Comment Edited] (VELOCITY-904) Add a flag for better backward compatibility with null macro arguments
[
https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [Comment Edited] (VELOCITY-904) Add a flag for better backward compatibility with null macro arguments
[
https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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
[
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
[
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
[
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
[
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] [Commented] (VELOCITY-904) Add a flag for better backward compatibility with null macro arguments
[
https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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-924) Bad cache handling for java.lang.Class methods
[
https://issues.apache.org/jira/browse/VELOCITY-924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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
[
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] [Comment Edited] (VELOCITY-924) Bad cache handling for java.lang.Class methods
[
https://issues.apache.org/jira/browse/VELOCITY-924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17011805#comment-17011805
]
Thomas Mortagne edited comment on VELOCITY-924 at 1/9/20 1:30 PM:
--
I just built a SNAPSHOT of Velocity trunk and while I don't get any error
anymore the new behavior is that it find no method at all instead of the wrong
one so still not great. For example in my use case it should call
TestClass#getName() but it does not find this method.
was (Author: tmortagne):
I just built a SNAPSHOT of Velocity trunk and while I don't get any error
anymore the new behavior is that it find no method at all instead of the wrong
one.
> Bad cache handling for java.lang.Class methods
> --
>
> Key: VELOCITY-924
> URL: https://issues.apache.org/jira/browse/VELOCITY-924
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.2
>Reporter: Thomas Mortagne
>Assignee: Claude Brisson
>Priority: Blocker
> Labels: regression
> Fix For: 2.2
>
>
> Requirement:
> A binding $var containing an object which class (org.xwiki.MyClass)
> implementing a {{String getName()}} method.
> The following code:
> {code}
> $var.class.getName()
> $var.getName()
> {code}
> fail with:
> {noformat}
> Caused by: org.apache.velocity.exception.MethodInvocationException:
> Invocation of method 'getName' in class org.xwiki.MyClass threw exception
> java.lang.IllegalArgumentException: object is not an instance of declaring
> class at mytemplaye[line 1, column 26]
> at
> org.apache.velocity.runtime.parser.node.ASTMethod.handleInvocationException(ASTMethod.java:306)
> at
> org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:239)
> at
> org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:369)
> at
> org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:490)
> at
> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:423)
> at org.apache.velocity.Template.merge(Template.java:358)
> at org.apache.velocity.Template.merge(Template.java:262)
> at
> org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:271)
> ... 69 more
> Caused by: java.lang.IllegalArgumentException: object is not an instance of
> declaring class
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:565)
> at
> org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:548)
> at
> org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:219)
> ... 75 more
> {noformat}
> The reason is that ClassUtils.getMethod cache does not make any difference
> between an instance of Class and and instance of
> org.xwiki.MyClass so when ASTMethod#execute ask for the second getName() it
> end up with Class#getName() instead of MyClass#getName().
> Was working fine in 1.7.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-924) Bad cache handling for java.lang.Class methods
[
https://issues.apache.org/jira/browse/VELOCITY-924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [Commented] (VELOCITY-924) Bad cache handling for java.lang.Class methods
[
https://issues.apache.org/jira/browse/VELOCITY-924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [Updated] (VELOCITY-924) Bad cache handling for java.lang.Class methods
[
https://issues.apache.org/jira/browse/VELOCITY-924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mortagne updated VELOCITY-924:
-
Labels: regression (was: )
> Bad cache handling for java.lang.Class methods
> --
>
> Key: VELOCITY-924
> URL: https://issues.apache.org/jira/browse/VELOCITY-924
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.2
>Reporter: Thomas Mortagne
>Priority: Blocker
> Labels: regression
>
> Requirement:
> A binding $var containing an object which class (org.xwiki.MyClass)
> implementing a {{String getName()}} method.
> The following code:
> {code}
> $var.class.getName()
> $var.getName()
> {code}
> fail with:
> {noformat}
> Caused by: org.apache.velocity.exception.MethodInvocationException:
> Invocation of method 'getName' in class org.xwiki.MyClass threw exception
> java.lang.IllegalArgumentException: object is not an instance of declaring
> class at mytemplaye[line 1, column 26]
> at
> org.apache.velocity.runtime.parser.node.ASTMethod.handleInvocationException(ASTMethod.java:306)
> at
> org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:239)
> at
> org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:369)
> at
> org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:490)
> at
> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:423)
> at org.apache.velocity.Template.merge(Template.java:358)
> at org.apache.velocity.Template.merge(Template.java:262)
> at
> org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:271)
> ... 69 more
> Caused by: java.lang.IllegalArgumentException: object is not an instance of
> declaring class
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:565)
> at
> org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:548)
> at
> org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:219)
> ... 75 more
> {noformat}
> The reason is that ClassUtils.getMethod cache does not make any difference
> between an instance of Class and and instance of
> org.xwiki.MyClass so when ASTMethod#execute ask for the second getName() it
> end up with Class#getName() instead of MyClass#getName().
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-924) Bad cache handling for java.lang.Class methods
[
https://issues.apache.org/jira/browse/VELOCITY-924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mortagne updated VELOCITY-924:
-
Description:
Requirement:
A binding $var containing an object which class (org.xwiki.MyClass)
implementing a {{String getName()}} method.
The following code:
{code}
$var.class.getName()
$var.getName()
{code}
fail with:
{noformat}
Caused by: org.apache.velocity.exception.MethodInvocationException: Invocation
of method 'getName' in class org.xwiki.MyClass threw exception
java.lang.IllegalArgumentException: object is not an instance of declaring
class at mytemplaye[line 1, column 26]
at
org.apache.velocity.runtime.parser.node.ASTMethod.handleInvocationException(ASTMethod.java:306)
at
org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:239)
at
org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:369)
at
org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:490)
at
org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:423)
at org.apache.velocity.Template.merge(Template.java:358)
at org.apache.velocity.Template.merge(Template.java:262)
at
org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:271)
... 69 more
Caused by: java.lang.IllegalArgumentException: object is not an instance of
declaring class
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:565)
at
org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:548)
at
org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:219)
... 75 more
{noformat}
The reason is that ClassUtils.getMethod cache does not make any difference
between an instance of Class and and instance of
org.xwiki.MyClass so when ASTMethod#execute ask for the second getName() it end
up with Class#getName() instead of MyClass#getName().
Was working fine in 1.7.
was:
Requirement:
A binding $var containing an object which class (org.xwiki.MyClass)
implementing a {{String getName()}} method.
The following code:
{code}
$var.class.getName()
$var.getName()
{code}
fail with:
{noformat}
Caused by: org.apache.velocity.exception.MethodInvocationException: Invocation
of method 'getName' in class org.xwiki.MyClass threw exception
java.lang.IllegalArgumentException: object is not an instance of declaring
class at mytemplaye[line 1, column 26]
at
org.apache.velocity.runtime.parser.node.ASTMethod.handleInvocationException(ASTMethod.java:306)
at
org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:239)
at
org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:369)
at
org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:490)
at
org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:423)
at org.apache.velocity.Template.merge(Template.java:358)
at org.apache.velocity.Template.merge(Template.java:262)
at
org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:271)
... 69 more
Caused by: java.lang.IllegalArgumentException: object is not an instance of
declaring class
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:565)
at
org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:548)
at
org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:219)
... 75 more
{noformat}
The reason is that ClassUtils.getMethod cache does not make any difference
between an instance of Class and and instance of
org.xwiki.MyClass so when ASTMethod#execute ask for the second getName() it end
up with Class#getName() instead of MyClass#getName().
> Bad cache handling for java.lang.Class methods
> --
>
> Key: VELOCITY-924
> URL: https://issues.apache.org/jira/browse/VELOCITY-924
> Project: Velocity
> Issue Type: Bug
>
[jira] [Created] (VELOCITY-924) Bad cache handling for java.lang.Class methods
Thomas Mortagne created VELOCITY-924:
Summary: Bad cache handling for java.lang.Class methods
Key: VELOCITY-924
URL: https://issues.apache.org/jira/browse/VELOCITY-924
Project: Velocity
Issue Type: Bug
Components: Engine
Affects Versions: 2.2
Reporter: Thomas Mortagne
Requirement:
A binding $var containing an object which class (org.xwiki.MyClass)
implementing a {{String getName()}} method.
The following code:
{code}
$var.class.getName()
$var.getName()
{code}
fail with:
{noformat}
Caused by: org.apache.velocity.exception.MethodInvocationException: Invocation
of method 'getName' in class org.xwiki.MyClass threw exception
java.lang.IllegalArgumentException: object is not an instance of declaring
class at mytemplaye[line 1, column 26]
at
org.apache.velocity.runtime.parser.node.ASTMethod.handleInvocationException(ASTMethod.java:306)
at
org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:239)
at
org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:369)
at
org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:490)
at
org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:423)
at org.apache.velocity.Template.merge(Template.java:358)
at org.apache.velocity.Template.merge(Template.java:262)
at
org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:271)
... 69 more
Caused by: java.lang.IllegalArgumentException: object is not an instance of
declaring class
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:565)
at
org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:548)
at
org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:219)
... 75 more
{noformat}
The reason is that ClassUtils.getMethod cache does not make any difference
between an instance of Class and and instance of
org.xwiki.MyClass so when ASTMethod#execute ask for the second getName() it end
up with Class#getName() instead of MyClass#getName().
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-904) Add a flag for better backward compatibility with null macro arguments
[
https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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
[
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
[
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] [Updated] (VELOCITY-923) New syntax error when || follow a Velocity expression
[
https://issues.apache.org/jira/browse/VELOCITY-923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mortagne updated VELOCITY-923:
-
Description:
The following fail in Velocity 2.2-SNAPSHOT:
{code}
$var||
{code}
but works fine in 1.7.
The workarounds is to put the expression inside {} (as in ${var})
Since || is a wiki syntax in our case it's not rare to see table cells or a
link reference containing a Velocity variable (without any {} protection since
it was working well in 1.7).
was:
The following fail in Velocity 2.2-SNAPSHOT:
{code}
$var||
{code}
but works fine in 1.7.
The workarounds is to put the expression inside {} (as in ${var})
Since || is a wiki syntax in our case it's not rare to see table cells or a
link label containing a Velocity variable (without any {} protection since it
was working well in 1.7).
> New syntax error when || follow a Velocity expression
> -
>
> Key: VELOCITY-923
> URL: https://issues.apache.org/jira/browse/VELOCITY-923
> Project: Velocity
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Thomas Mortagne
>Priority: Blocker
> Labels: regression
>
> The following fail in Velocity 2.2-SNAPSHOT:
> {code}
> $var||
> {code}
> but works fine in 1.7.
> The workarounds is to put the expression inside {} (as in ${var})
> Since || is a wiki syntax in our case it's not rare to see table cells or a
> link reference containing a Velocity variable (without any {} protection
> since it was working well in 1.7).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-923) New syntax error when || follow a Velocity expression
[
https://issues.apache.org/jira/browse/VELOCITY-923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mortagne updated VELOCITY-923:
-
Description:
The following fail in Velocity 2.2-SNAPSHOT:
{code}
$var||
{code}
but works fine in 1.7.
The workarounds is to put the expression inside {} (as in ${var})
Since || is a wiki syntax in our case it's not rare to see table cells or a
link label containing a Velocity variable (without any {} protection since it
was working well in 1.7).
was:
The following fail in Velocity 2.2-SNAPSHOT:
{code}
$var||
{code}
but works fine in 1.7.
The workarounds is to put the expression inside {} (as in ${var})
Since || is a wiki syntax in our case it's not rare to see table cells
containing a Velocity variable (without any {} protection since it was working
well in 1.7).
> New syntax error when || follow a Velocity expression
> -
>
> Key: VELOCITY-923
> URL: https://issues.apache.org/jira/browse/VELOCITY-923
> Project: Velocity
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Thomas Mortagne
>Priority: Blocker
> Labels: regression
>
> The following fail in Velocity 2.2-SNAPSHOT:
> {code}
> $var||
> {code}
> but works fine in 1.7.
> The workarounds is to put the expression inside {} (as in ${var})
> Since || is a wiki syntax in our case it's not rare to see table cells or a
> link label containing a Velocity variable (without any {} protection since it
> was working well in 1.7).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-923) New syntax error when || follow a Velocity expression
[
https://issues.apache.org/jira/browse/VELOCITY-923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mortagne updated VELOCITY-923:
-
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] [Created] (VELOCITY-923) New syntax error when || follow a Velocity expression
Thomas Mortagne created VELOCITY-923:
Summary: New syntax error when || follow a Velocity expression
Key: VELOCITY-923
URL: https://issues.apache.org/jira/browse/VELOCITY-923
Project: Velocity
Issue Type: Bug
Affects Versions: 2.2
Reporter: Thomas Mortagne
The following fail in Velocity 2.2-SNAPSHOT:
{code}
$var||
{code}
but works fine in 1.7.
The workarounds is to put the expression inside {} (as in ${var})
Since || is a wiki syntax in our case it's not rare to see table cells
containing a Velocity variable (without any {} protection since it was working
well in 1.7).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-923) New syntax error when || follow a Velocity expression
[
https://issues.apache.org/jira/browse/VELOCITY-923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mortagne updated VELOCITY-923:
-
Labels: regresion (was: )
> New syntax error when || follow a Velocity expression
> -
>
> Key: VELOCITY-923
> URL: https://issues.apache.org/jira/browse/VELOCITY-923
> Project: Velocity
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Thomas Mortagne
>Priority: Blocker
> Labels: regresion
>
> The following fail in Velocity 2.2-SNAPSHOT:
> {code}
> $var||
> {code}
> but works fine in 1.7.
> The workarounds is to put the expression inside {} (as in ${var})
> Since || is a wiki syntax in our case it's not rare to see table cells
> containing a Velocity variable (without any {} protection since it was
> working well in 1.7).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-904) Add a flag for better backward compatibility with null macro arguments
[
https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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
[
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] [Commented] (VELOCITY-904) Add a flag for better backward compatibility with null macro arguments
[
https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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-904) Add a flag for better backward compatibility with null macro arguments
[
https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [Commented] (VELOCITY-918) Using commons-collection version 3.2.1 which having vulnerabilities
[ https://issues.apache.org/jira/browse/VELOCITY-918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [Comment Edited] (VELOCITY-896) Regression in the handling of String literal ending with a sharp sign
[
https://issues.apache.org/jira/browse/VELOCITY-896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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-896) Regression in the handling of String literal ending with a sharp sign
[
https://issues.apache.org/jira/browse/VELOCITY-896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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-892) Method arguments conversions should be based on Type instead of Class
[ https://issues.apache.org/jira/browse/VELOCITY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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
[ 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] [Comment Edited] (VELOCITY-892) Method arguments conversions should be based on Type instead of Class
[ https://issues.apache.org/jira/browse/VELOCITY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654029#comment-16654029 ] Thomas Mortagne edited comment on VELOCITY-892 at 10/17/18 6:43 PM: bq. Well, to my mind, whether Velocity is Type-aware I never suggested that Velocity should not be Type aware. I'm just saying that there is two different levels: * provide a custom converter handler * provide custom converters to the default converter handler Just trying to make sure that I will be able to cover all XWiki use cases with the new APIs provided by Velocity. Since current system is working well I don't want to spend a lot of time on refactoring it to break things basically. was (Author: tmortagne): bq. Well, to my mind, whether Velocity is Type-aware I never suggested that Velocity should not be Type aware. I'm just saying that there is two different levels: * provide a custom converter handler * provide custom converters to the default converter handler > Method arguments conversions should be based on Type instead of Class > - > > Key: VELOCITY-892 > URL: https://issues.apache.org/jira/browse/VELOCITY-892 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.0 >Reporter: Thomas Mortagne >Priority: Major > Fix For: 2.0 > > > I was happy to see that method arguments conversion has been added to 2.0 so > that I can remove the uberspector we have on XWiki side but unfortunately > ConversionHandler is limited to classes which is way too restrictive for us > (for example if the parameter type is List it won't do the same thing > than if the type is List). > Our uberspector can be found on > https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodArgumentsUberspector.java > to see what we do exactly. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-892) Method arguments conversions should be based on Type instead of Class
[ https://issues.apache.org/jira/browse/VELOCITY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654029#comment-16654029 ] Thomas Mortagne commented on VELOCITY-892: -- bq. Well, to my mind, whether Velocity is Type-aware I never suggested that Velocity should not be Type aware. I'm just saying that there is two different levels: * provider a custom converter handler * provider custom converters to the default converter handler > Method arguments conversions should be based on Type instead of Class > - > > Key: VELOCITY-892 > URL: https://issues.apache.org/jira/browse/VELOCITY-892 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.0 >Reporter: Thomas Mortagne >Priority: Major > Fix For: 2.0 > > > I was happy to see that method arguments conversion has been added to 2.0 so > that I can remove the uberspector we have on XWiki side but unfortunately > ConversionHandler is limited to classes which is way too restrictive for us > (for example if the parameter type is List it won't do the same thing > than if the type is List). > Our uberspector can be found on > https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodArgumentsUberspector.java > to see what we do exactly. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-892) Method arguments conversions should be based on Type instead of Class
[ https://issues.apache.org/jira/browse/VELOCITY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [Comment Edited] (VELOCITY-892) Method arguments conversions should be based on Type instead of Class
[ https://issues.apache.org/jira/browse/VELOCITY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16653786#comment-16653786 ] Thomas Mortagne edited comment on VELOCITY-892 at 10/17/18 4:29 PM: Actually my plan was to implement a ConversionHandler and not add a set of converters since XWiki already have a conversion system which is used in https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodArgumentsUberspector.java for example. So my issue is more with #getNeededConverter being asked a Class instead of a Type. Note that in our uberspector the logic is a bit different, if it does not find any matching method it directly try to convert the parameters for each method until it find one for which the conversion did not failed. For example even if there is a Converter available for Integer, the passed String might not actually be a number in which case the conversion will fail and it will try another method which expect some enum and this time it works fine. This is because our converter support really quite a lot of types which mean asking if a converter exist for a type does not give much information for the purpose of parameters conversion. was (Author: tmortagne): Actually my plan was to implement a ConversionHandler and not add a set of converters since XWiki already have a conversion system which is used in https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodArgumentsUberspector.java for example. So my issue is more with #getNeededConverter being asked a Class instead of a Type. > Method arguments conversions should be based on Type instead of Class > - > > Key: VELOCITY-892 > URL: https://issues.apache.org/jira/browse/VELOCITY-892 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.0 >Reporter: Thomas Mortagne >Priority: Major > Fix For: 2.0 > > > I was happy to see that method arguments conversion has been added to 2.0 so > that I can remove the uberspector we have on XWiki side but unfortunately > ConversionHandler is limited to classes which is way too restrictive for us > (for example if the parameter type is List it won't do the same thing > than if the type is List). > Our uberspector can be found on > https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodArgumentsUberspector.java > to see what we do exactly. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-892) Method arguments conversions should be based on Type instead of Class
[ https://issues.apache.org/jira/browse/VELOCITY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [Commented] (VELOCITY-892) Method arguments conversions should be based on Type instead of Class
[ https://issues.apache.org/jira/browse/VELOCITY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16653786#comment-16653786 ] Thomas Mortagne commented on VELOCITY-892: -- Actually my plan was to implement a ConversionHandler and not add a set of converters since XWiki already have a conversion system which is used in https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodArgumentsUberspector.java for example. > Method arguments conversions should be based on Type instead of Class > - > > Key: VELOCITY-892 > URL: https://issues.apache.org/jira/browse/VELOCITY-892 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.0 >Reporter: Thomas Mortagne >Priority: Major > Fix For: 2.0 > > > I was happy to see that method arguments conversion has been added to 2.0 so > that I can remove the uberspector we have on XWiki side but unfortunately > ConversionHandler is limited to classes which is way too restrictive for us > (for example if the parameter type is List it won't do the same thing > than if the type is List). > Our uberspector can be found on > https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodArgumentsUberspector.java > to see what we do exactly. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-892) Method arguments conversions should be based on Type instead of Class
[ https://issues.apache.org/jira/browse/VELOCITY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16653111#comment-16653111 ] Thomas Mortagne edited comment on VELOCITY-892 at 10/17/18 7:22 AM: bq. because it's painful to have the API evolve Yeah always a pain. One possibility I guess is having two kind of converters and call one after the other but yes never nice to have to support the one you don't want people to use anymore. Thanks for taking this into consideration ! was (Author: tmortagne): bq. because it's painful to have the API evolve Yeah always a pain. One possibility I guess is having two kind of converters and call one after the other but yes never nice to have to support the one you don't want people to use anymore. > Method arguments conversions should be based on Type instead of Class > - > > Key: VELOCITY-892 > URL: https://issues.apache.org/jira/browse/VELOCITY-892 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.0 >Reporter: Thomas Mortagne >Priority: Major > Fix For: 2.0 > > > I was happy to see that method arguments conversion has been added to 2.0 so > that I can remove the uberspector we have on XWiki side but unfortunately > ConversionHandler is limited to classes which is way too restrictive for us > (for example if the parameter type is List it won't do the same thing > than if the type is List). > Our uberspector can be found on > https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodArgumentsUberspector.java > to see what we do exactly. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-892) Method arguments conversions should be based on Type instead of Class
[ https://issues.apache.org/jira/browse/VELOCITY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16653111#comment-16653111 ] Thomas Mortagne commented on VELOCITY-892: -- bq. because it's painful to have the API evolve Yeah always a pain. One possibility I guess is having two kind of converters and call one after the other but yes never nice to have to support the one you don't want people to use anymore. > Method arguments conversions should be based on Type instead of Class > - > > Key: VELOCITY-892 > URL: https://issues.apache.org/jira/browse/VELOCITY-892 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.0 >Reporter: Thomas Mortagne >Priority: Major > Fix For: 2.0 > > > I was happy to see that method arguments conversion has been added to 2.0 so > that I can remove the uberspector we have on XWiki side but unfortunately > ConversionHandler is limited to classes which is way too restrictive for us > (for example if the parameter type is List it won't do the same thing > than if the type is List). > Our uberspector can be found on > https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodArgumentsUberspector.java > to see what we do exactly. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-892) Method arguments conversions should be based on Type instead of Class
[ https://issues.apache.org/jira/browse/VELOCITY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [Commented] (VELOCITY-542) minus sign in #set requires spaces to surround it
[ https://issues.apache.org/jira/browse/VELOCITY-542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [Comment Edited] (VELOCITY-892) Method arguments conversions should be based on Type instead of Class
[
https://issues.apache.org/jira/browse/VELOCITY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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
[
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] [Commented] (VELOCITY-896) Regression in the handling of String literal ending with a sharp sign
[
https://issues.apache.org/jira/browse/VELOCITY-896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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
[
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
[ 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] [Comment Edited] (VELOCITY-896) Regression in the handling of String literal ending with a sharp sign
[
https://issues.apache.org/jira/browse/VELOCITY-896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [Comment Edited] (VELOCITY-896) Regression in the handling of String literal ending with a sharp sign
[
https://issues.apache.org/jira/browse/VELOCITY-896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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-896) Regression in the handling of String literal ending with a sharp sign
[
https://issues.apache.org/jira/browse/VELOCITY-896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [Commented] (VELOCITY-901) hyphen in identifiers cause parse error
[ https://issues.apache.org/jira/browse/VELOCITY-901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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-901) hyphen in identifiers cause parse error
[
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] [Comment Edited] (VELOCITY-900) Velocity.evalute thows an exception if the next char after a keyword is '_'
[
https://issues.apache.org/jira/browse/VELOCITY-900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16605622#comment-16605622
]
Thomas Mortagne edited comment on VELOCITY-900 at 9/6/18 10:46 AM:
---
This is probably because Velocity thinks you are trying to call the directive
"end__" since _ is valid in a directive name. You can workaround it by using
{noformat}#{end}{noformat}.
was (Author: tmortagne):
This is probably because Velocity thinks you are trying to call the directive
"end__" since _ is valid in a directive name. You can workaround it by using
{{#{end}}}.
> Velocity.evalute thows an exception if the next char after a keyword is '_'
> ---
>
> Key: VELOCITY-900
> URL: https://issues.apache.org/jira/browse/VELOCITY-900
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.0
> Environment: Win 7, Java 8
>Reporter: Alto
>Priority: Major
>
> If I try to evalute the folling template "CONSTRAINT
> DF_#if(${archiveTableTemplate})${archiveTableTemplate}#else${table}#end__${column}"
> an exception is thrown.
> Velocity.evaluate(myContext, myStringWriter, "LOG", template); = >Exception
> occurred in target VM: Encountered "" at LOG[line 1, column 93]
> Was expecting one of:
> "(" ...
> ")" ...
> ...
> "]]#" ...
> ...
> ...
> ...
> ...
> ...
> ...
> ...
> "{" ...
> "}" ...
> "" ...
> "\\" ...
> ...
> ...
> ...
> "{" ...
> <
> If I use the Template "CONSTRAINT
> DF_#if(${archiveTableTemplate})${archiveTableTemplate}#else${table}#end
> __${column}" it works, but the result is wrong. Blank after replacement.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-900) Velocity.evalute thows an exception if the next char after a keyword is '_'
[
https://issues.apache.org/jira/browse/VELOCITY-900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16605622#comment-16605622
]
Thomas Mortagne commented on VELOCITY-900:
--
This is probably because Velocity thinks you are trying to call the directive
"end__" since _ is valid in a directive name. You can workaround it by using
{{#{end}}}.
> Velocity.evalute thows an exception if the next char after a keyword is '_'
> ---
>
> Key: VELOCITY-900
> URL: https://issues.apache.org/jira/browse/VELOCITY-900
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.0
> Environment: Win 7, Java 8
>Reporter: Alto
>Priority: Major
>
> If I try to evalute the folling template "CONSTRAINT
> DF_#if(${archiveTableTemplate})${archiveTableTemplate}#else${table}#end__${column}"
> an exception is thrown.
> Velocity.evaluate(myContext, myStringWriter, "LOG", template); = >Exception
> occurred in target VM: Encountered "" at LOG[line 1, column 93]
> Was expecting one of:
> "(" ...
> ")" ...
> ...
> "]]#" ...
> ...
> ...
> ...
> ...
> ...
> ...
> ...
> "{" ...
> "}" ...
> "" ...
> "\\" ...
> ...
> ...
> ...
> "{" ...
> <
> If I use the Template "CONSTRAINT
> DF_#if(${archiveTableTemplate})${archiveTableTemplate}#else${table}#end
> __${column}" it works, but the result is wrong. Blank after replacement.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-900) Velocity.evalute thows an exception if the next char after a keyword is '_'
[
https://issues.apache.org/jira/browse/VELOCITY-900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [Updated] (VELOCITY-896) Regression in the handling of String literal ending with a sharp sign
[
https://issues.apache.org/jira/browse/VELOCITY-896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mortagne updated VELOCITY-896:
-
Description:
The following produce a ParseErrorException after upgrading to Velocity 2:
{code}
#set($var = "#")
{code}
or
{code}
#set($var = "toto#")
{code}
{noformat}
org.xwiki.velocity.XWikiVelocityException: Failed to evaluate content with id
[mytemplate]
at
org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:279)
at
org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:244)
at
org.xwiki.velocity.internal.DefaultVelocityEngineTest.assertEvaluate(DefaultVelocityEngineTest.java:92)
at
org.xwiki.velocity.internal.DefaultVelocityEngineTest.assertEvaluate(DefaultVelocityEngineTest.java:85)
at
org.xwiki.velocity.internal.DefaultVelocityEngineTest.testMisc(DefaultVelocityEngineTest.java:287)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:436)
at
org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:115)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$6(TestMethodTestDescriptor.java:170)
at
org.junit.jupiter.engine.execution.ThrowableCollector.execute(ThrowableCollector.java:40)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:166)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:113)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:58)
at
org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$3(HierarchicalTestExecutor.java:112)
at
org.junit.platform.engine.support.hierarchical.SingleTestExecutor.executeSafely(SingleTestExecutor.java:66)
at
org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.executeRecursively(HierarchicalTestExecutor.java:108)
at
org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.execute(HierarchicalTestExecutor.java:79)
at
org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$2(HierarchicalTestExecutor.java:120)
at
java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
at
java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
at java.util.Iterator.forEachRemaining(Iterator.java:116)
at
java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
at
java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
at
java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
at
java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at
java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
at
org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$3(HierarchicalTestExecutor.java:120)
at
org.junit.platform.engine.support.hierarchical.SingleTestExecutor.executeSafely(SingleTestExecutor.java:66)
at
org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.executeRecursively(HierarchicalTestExecutor.java:108)
at
org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.execute(HierarchicalTestExecutor.java:79)
at
org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$2(HierarchicalTestExecutor.java:120)
at
java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
at
java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
at java.util.Iterator.forEachRemaining(Iterator.java:116)
at
java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
at
java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
at
[jira] [Created] (VELOCITY-897) Regression in the handling of String literal ending with a dollar sign
Thomas Mortagne created VELOCITY-897:
Summary: Regression in the handling of String literal ending with
a dollar sign
Key: VELOCITY-897
URL: https://issues.apache.org/jira/browse/VELOCITY-897
Project: Velocity
Issue Type: Bug
Affects Versions: 2.0
Reporter: Thomas Mortagne
Same as VELOCITY-896 but this time with dollar sign ($).
For example
{code}
#set($var = "$")
{code}
or
{code}
#set($var = "toto$")
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-896) Regression in the handling of String literal ending with a sharp sign
[
https://issues.apache.org/jira/browse/VELOCITY-896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mortagne updated VELOCITY-896:
-
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] [Updated] (VELOCITY-896) Regression in the handling of String literal ending with a sharp
[
https://issues.apache.org/jira/browse/VELOCITY-896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mortagne updated VELOCITY-896:
-
Description:
The following produce a ParseErrorException after upgrading to Velocity 2:
{code}
#set($var = "#")
{code}
or
{code}
#set($var = "toto#")
{code}
{noformat}
org.xwiki.velocity.XWikiVelocityException: Failed to evaluate content with id
[mytemplate]
at
org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:279)
at
org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:244)
at
org.xwiki.velocity.internal.DefaultVelocityEngineTest.assertEvaluate(DefaultVelocityEngineTest.java:92)
at
org.xwiki.velocity.internal.DefaultVelocityEngineTest.assertEvaluate(DefaultVelocityEngineTest.java:85)
at
org.xwiki.velocity.internal.DefaultVelocityEngineTest.testMisc(DefaultVelocityEngineTest.java:287)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:436)
at
org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:115)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$6(TestMethodTestDescriptor.java:170)
at
org.junit.jupiter.engine.execution.ThrowableCollector.execute(ThrowableCollector.java:40)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:166)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:113)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:58)
at
org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$3(HierarchicalTestExecutor.java:112)
at
org.junit.platform.engine.support.hierarchical.SingleTestExecutor.executeSafely(SingleTestExecutor.java:66)
at
org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.executeRecursively(HierarchicalTestExecutor.java:108)
at
org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.execute(HierarchicalTestExecutor.java:79)
at
org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$2(HierarchicalTestExecutor.java:120)
at
java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
at
java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
at java.util.Iterator.forEachRemaining(Iterator.java:116)
at
java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
at
java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
at
java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
at
java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at
java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
at
org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$3(HierarchicalTestExecutor.java:120)
at
org.junit.platform.engine.support.hierarchical.SingleTestExecutor.executeSafely(SingleTestExecutor.java:66)
at
org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.executeRecursively(HierarchicalTestExecutor.java:108)
at
org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.execute(HierarchicalTestExecutor.java:79)
at
org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$2(HierarchicalTestExecutor.java:120)
at
java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
at
java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
at java.util.Iterator.forEachRemaining(Iterator.java:116)
at
java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
at
java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
at
[jira] [Updated] (VELOCITY-896) Regression in the handling of String literal ending with a sharp
[
https://issues.apache.org/jira/browse/VELOCITY-896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mortagne updated VELOCITY-896:
-
Summary: Regression in the handling of String literal ending with a sharp
(was: Regression in the handling of string containing a sharp)
> Regression in the handling of String literal ending with a sharp
>
>
> Key: VELOCITY-896
> URL: https://issues.apache.org/jira/browse/VELOCITY-896
> Project: Velocity
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Thomas Mortagne
>Priority: Blocker
>
> The following produce a ParseErrorException after upgrading to Velocity 2:
> {code}
> #set($var = "#")
> {code}
> {noformat}
> org.xwiki.velocity.XWikiVelocityException: Failed to evaluate content with id
> [mytemplate]
> at
> org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:279)
> at
> org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:244)
> at
> org.xwiki.velocity.internal.DefaultVelocityEngineTest.assertEvaluate(DefaultVelocityEngineTest.java:92)
> at
> org.xwiki.velocity.internal.DefaultVelocityEngineTest.assertEvaluate(DefaultVelocityEngineTest.java:85)
> at
> org.xwiki.velocity.internal.DefaultVelocityEngineTest.testMisc(DefaultVelocityEngineTest.java:287)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:436)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:115)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$6(TestMethodTestDescriptor.java:170)
> at
> org.junit.jupiter.engine.execution.ThrowableCollector.execute(ThrowableCollector.java:40)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:166)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:113)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:58)
> at
> org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$3(HierarchicalTestExecutor.java:112)
> at
> org.junit.platform.engine.support.hierarchical.SingleTestExecutor.executeSafely(SingleTestExecutor.java:66)
> at
> org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.executeRecursively(HierarchicalTestExecutor.java:108)
> at
> org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.execute(HierarchicalTestExecutor.java:79)
> at
> org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$2(HierarchicalTestExecutor.java:120)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
> at
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
> at
> org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$3(HierarchicalTestExecutor.java:120)
> at
> org.junit.platform.engine.support.hierarchical.SingleTestExecutor.executeSafely(SingleTestExecutor.java:66)
> at
> org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.executeRecursively(HierarchicalTestExecutor.java:108)
> at
> org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.execute(HierarchicalTestExecutor.java:79)
> at
>
[jira] [Updated] (VELOCITY-896) Regression in the handling of string containing a sharp
[
https://issues.apache.org/jira/browse/VELOCITY-896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mortagne updated VELOCITY-896:
-
Description:
The following produce a ParseErrorException after upgrading to Velocity 2:
{code}
#set($var = "#")
{code}
{noformat}
org.xwiki.velocity.XWikiVelocityException: Failed to evaluate content with id
[mytemplate]
at
org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:279)
at
org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:244)
at
org.xwiki.velocity.internal.DefaultVelocityEngineTest.assertEvaluate(DefaultVelocityEngineTest.java:92)
at
org.xwiki.velocity.internal.DefaultVelocityEngineTest.assertEvaluate(DefaultVelocityEngineTest.java:85)
at
org.xwiki.velocity.internal.DefaultVelocityEngineTest.testMisc(DefaultVelocityEngineTest.java:287)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:436)
at
org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:115)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$6(TestMethodTestDescriptor.java:170)
at
org.junit.jupiter.engine.execution.ThrowableCollector.execute(ThrowableCollector.java:40)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:166)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:113)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:58)
at
org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$3(HierarchicalTestExecutor.java:112)
at
org.junit.platform.engine.support.hierarchical.SingleTestExecutor.executeSafely(SingleTestExecutor.java:66)
at
org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.executeRecursively(HierarchicalTestExecutor.java:108)
at
org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.execute(HierarchicalTestExecutor.java:79)
at
org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$2(HierarchicalTestExecutor.java:120)
at
java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
at
java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
at java.util.Iterator.forEachRemaining(Iterator.java:116)
at
java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
at
java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
at
java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
at
java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at
java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
at
org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$3(HierarchicalTestExecutor.java:120)
at
org.junit.platform.engine.support.hierarchical.SingleTestExecutor.executeSafely(SingleTestExecutor.java:66)
at
org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.executeRecursively(HierarchicalTestExecutor.java:108)
at
org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.execute(HierarchicalTestExecutor.java:79)
at
org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$2(HierarchicalTestExecutor.java:120)
at
java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
at
java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
at java.util.Iterator.forEachRemaining(Iterator.java:116)
at
java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
at
java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
at
java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
[jira] [Created] (VELOCITY-896) Regression in the handling of string containing a sharp
Thomas Mortagne created VELOCITY-896:
Summary: Regression in the handling of string containing a sharp
Key: VELOCITY-896
URL: https://issues.apache.org/jira/browse/VELOCITY-896
Project: Velocity
Issue Type: Bug
Affects Versions: 2.0
Reporter: Thomas Mortagne
The following produce a ParseErrorException after upgrading to Velocity 2:
{code}
#set($var = "#")
{code}
{noformat}
org.xwiki.velocity.XWikiVelocityException: Failed to evaluate content with id
[mytemplate]
at
org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:279)
at
org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:244)
at
org.xwiki.velocity.internal.DefaultVelocityEngineTest.assertEvaluate(DefaultVelocityEngineTest.java:92)
at
org.xwiki.velocity.internal.DefaultVelocityEngineTest.assertEvaluate(DefaultVelocityEngineTest.java:85)
at
org.xwiki.velocity.internal.DefaultVelocityEngineTest.testMisc(DefaultVelocityEngineTest.java:287)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:436)
at
org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:115)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$6(TestMethodTestDescriptor.java:170)
at
org.junit.jupiter.engine.execution.ThrowableCollector.execute(ThrowableCollector.java:40)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:166)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:113)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:58)
at
org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$3(HierarchicalTestExecutor.java:112)
at
org.junit.platform.engine.support.hierarchical.SingleTestExecutor.executeSafely(SingleTestExecutor.java:66)
at
org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.executeRecursively(HierarchicalTestExecutor.java:108)
at
org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.execute(HierarchicalTestExecutor.java:79)
at
org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$2(HierarchicalTestExecutor.java:120)
at
java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
at
java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
at java.util.Iterator.forEachRemaining(Iterator.java:116)
at
java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
at
java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
at
java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
at
java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at
java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
at
org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$3(HierarchicalTestExecutor.java:120)
at
org.junit.platform.engine.support.hierarchical.SingleTestExecutor.executeSafely(SingleTestExecutor.java:66)
at
org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.executeRecursively(HierarchicalTestExecutor.java:108)
at
org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.execute(HierarchicalTestExecutor.java:79)
at
org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$2(HierarchicalTestExecutor.java:120)
at
java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
at
java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
at java.util.Iterator.forEachRemaining(Iterator.java:116)
at
java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
at
[jira] [Updated] (VELOCITY-896) Regression in the handling of string containing a sharp
[
https://issues.apache.org/jira/browse/VELOCITY-896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mortagne updated VELOCITY-896:
-
Description:
The following produce a ParseErrorException after upgrading to Velocity 2:
{code}
#set($var = "#")
{code}
{noformat}
org.xwiki.velocity.XWikiVelocityException: Failed to evaluate content with id
[mytemplate]
at
org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:279)
at
org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:244)
at
org.xwiki.velocity.internal.DefaultVelocityEngineTest.assertEvaluate(DefaultVelocityEngineTest.java:92)
at
org.xwiki.velocity.internal.DefaultVelocityEngineTest.assertEvaluate(DefaultVelocityEngineTest.java:85)
at
org.xwiki.velocity.internal.DefaultVelocityEngineTest.testMisc(DefaultVelocityEngineTest.java:287)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:436)
at
org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:115)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$6(TestMethodTestDescriptor.java:170)
at
org.junit.jupiter.engine.execution.ThrowableCollector.execute(ThrowableCollector.java:40)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:166)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:113)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:58)
at
org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$3(HierarchicalTestExecutor.java:112)
at
org.junit.platform.engine.support.hierarchical.SingleTestExecutor.executeSafely(SingleTestExecutor.java:66)
at
org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.executeRecursively(HierarchicalTestExecutor.java:108)
at
org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.execute(HierarchicalTestExecutor.java:79)
at
org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$2(HierarchicalTestExecutor.java:120)
at
java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
at
java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
at java.util.Iterator.forEachRemaining(Iterator.java:116)
at
java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
at
java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
at
java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
at
java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at
java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
at
org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$3(HierarchicalTestExecutor.java:120)
at
org.junit.platform.engine.support.hierarchical.SingleTestExecutor.executeSafely(SingleTestExecutor.java:66)
at
org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.executeRecursively(HierarchicalTestExecutor.java:108)
at
org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.execute(HierarchicalTestExecutor.java:79)
at
org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$2(HierarchicalTestExecutor.java:120)
at
java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
at
java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
at java.util.Iterator.forEachRemaining(Iterator.java:116)
at
java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
at
java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
at
java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
[jira] [Commented] (VELOCITY-894) Maven central JARs don't contains debug information
[ https://issues.apache.org/jira/browse/VELOCITY-894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [Updated] (VELOCITY-894) Maven central JARs don't contains debug information
[ https://issues.apache.org/jira/browse/VELOCITY-894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mortagne updated VELOCITY-894: - Description: As far as I can see the JAR published on velocity-engine-core-2.0.java published on Maven central has been built without the debug information. Makes is quite a pain to understand what happen exactly when you have something to debug. (was: As far as I can see the JAR published on velocity-engine-core-2.0.java published on Maven central has been built without the debug information. Makes is quite a pain to understand when happen exactly when you have something to debug.) > Maven central JARs don't contains debug information > --- > > Key: VELOCITY-894 > URL: https://issues.apache.org/jira/browse/VELOCITY-894 > Project: Velocity > Issue Type: Bug > Components: Build >Affects Versions: 2.0 >Reporter: Thomas Mortagne >Priority: Major > > As far as I can see the JAR published on velocity-engine-core-2.0.java > published on Maven central has been built without the debug information. > Makes is quite a pain to understand what happen exactly when you have > something to debug. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
