[jira] [Commented] (VELOCITY-969) Lower scripts parser performance after update from 1.6 to 2.3 velocity version
[ https://issues.apache.org/jira/browse/VELOCITY-969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17794167#comment-17794167 ] Claude Brisson commented on VELOCITY-969: - We can potentially do something if we can reproduce the problem, or preferably if you can help us track down the origin of the regression by doing some profiling. > Lower scripts parser performance after update from 1.6 to 2.3 velocity version > -- > > Key: VELOCITY-969 > URL: https://issues.apache.org/jira/browse/VELOCITY-969 > Project: Velocity > Issue Type: Bug >Reporter: Magdalena Karpierz >Priority: Critical > > Hello Team, > > We have problems after update velocity 1.6.3 to 2.3 version with parsing > performance of the scripts which include many macros inside and overall > lenght of the script is about 3000 lines. > Performance execution of this kind of scripts decreased 10 times, example > script execution in velocity1 took: 1sec. and in velocity2: 6 to 10 seconds. > > Did You observe such performance issues? > Can You suggest us a potential solution for this problem? > > I prioritized this ticket as a critical, because our customers saw this > immediately and it blocks some further activities. -- 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-969) Lower scripts parser performance after update from 1.6 to 2.3 velocity version
Magdalena Karpierz created VELOCITY-969: --- Summary: Lower scripts parser performance after update from 1.6 to 2.3 velocity version Key: VELOCITY-969 URL: https://issues.apache.org/jira/browse/VELOCITY-969 Project: Velocity Issue Type: Bug Reporter: Magdalena Karpierz Hello Team, We have problems after update velocity 1.6.3 to 2.3 version with parsing performance of the scripts which include many macros inside and overall lenght of the script is about 3000 lines. Performance execution of this kind of scripts decreased 10 times, example script execution in velocity1 took: 1sec. and in velocity2: 6 to 10 seconds. Did You observe such performance issues? Can You suggest us a potential solution for this problem? I prioritized this ticket as a critical, because our customers saw this immediately and it blocks some further activities. -- 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&focusedCommentId=17772341#comment-17772341
]
Christopher Schultz commented on VELOCITY-952:
--
I reported this as VELOCITY-968 and offered the following as a suggestion. I
don't know how the introspector works, so I'm just waving my hands, here:
"
Maybe
org.apache.velocity.util.introspection.MethodMap.getBestMatch(List,
Class[]) can choose a superclass method over a subclass method if they are
otherwise equivalent?
"
I've read the documentation for MethodOverrideUberspector.java and I think if
you just always use the most-superclass-or-superinterface method available,
many of these issues can be avoided without any additional overhead of
remembering the return-type of certain "get" invocations. This will also help
when Velocity wasn't responsible for performing the original access, for
example when the object is just dropped into the context by Java code and has a
runtime type different from the declared type in the code.
> 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 i
[jira] [Resolved] (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:all-tabpanel
]
Christopher Schultz resolved VELOCITY-968.
--
Resolution: Duplicate
Duplicate 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
[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&focusedCommentId=17772338#comment-17772338
]
Christopher Schultz commented on VELOCITY-968:
--
Yes, it does indeed look like a duplicate. Apologies. I did search, but the
description of VELOCITY-952 didn't seem to match and I didn't read the details.
> 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"
> + "A1UEChMHVW5rbm93bjEQMA4GA1UECxMHVW5
[jira] [Comment Edited] (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&focusedCommentId=17772335#comment-17772335
]
Christopher Schultz edited comment on VELOCITY-968 at 10/5/23 6:28 PM:
---
Maybe
org.apache.velocity.util.introspection.MethodMap.getBestMatch(List,
Class[]) can choose a superclass method over a subclass method if they are
otherwise equivalent?
was (Author: ch...@christopherschultz.net):
Maybe
`org.apache.velocity.util.introspection.MethodMap.getBestMatch(List,
Class[])` can choose a superclass method over a subclass method if they are
otherwise equivalent?
> 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
[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&focusedCommentId=17772335#comment-17772335
]
Christopher Schultz commented on VELOCITY-968:
--
Maybe
`org.apache.velocity.util.introspection.MethodMap.getBestMatch(List,
Class[])` can choose a superclass method over a subclass method if they are
otherwise equivalent?
> 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"
> + "A1UEChMHVW5rbm93bjEQMA4GA1UECxMHVW5rbm93bjENM
[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&focusedCommentId=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"
> + "d24xEDAOBgNVBAgTB1V
[jira] [Updated] (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:all-tabpanel
]
Christopher Schultz updated VELOCITY-968:
-
Description:
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"
+ "dzOrCDAKBggqhkjOPQQDAwNnADBkAjBx+sqV2gzUusdOvwltH7f7sp5UtZMRFKF4\n"
+ "mRcGA7buAZN/YPUGgkiUZ6ZEJmw8Dn8CMEEgm8c2WTYdO/CQ5DRBbfIt1TcpiDxk\n"
+ "0vM+YZrSctwCJhK+3h3i4X990XvjJQ3Hmw==\n"
+ "-END CERTIFICATE-\n"
;
private static final String templateText = "Test: $cert.notAfter\n";
public static void main(String[] args) throws Exception {
X509Certificate cert =
(X509Certificate)CertificateFactory.getInstance("X.509").generateCertificate(new
java.io.ByteArrayInputStream(certText.getBytes(StandardCharset
[jira] [Created] (VELOCITY-968) In Java 17+, introspection fails in many cases due to permissions
Christopher Schultz created VELOCITY-968:
Summary: 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: 2.3, 1.7.x
Environment: Java 17
Reporter: Christopher Schultz
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:/Users/christopherschultz/Documents/Eclipse/chadis-web/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"
+ "dzOrCDAKBggqhkjOPQQDAwNnADBkAjBx+sqV2gzUusdOvwltH7f7sp5UtZMRFKF4\n"
+ "mRcGA7buAZN/YPUGgkiUZ6ZEJmw8Dn8CMEEgm8c2WTYdO/CQ5DRBbfIt1TcpiDxk\n"
+ "0vM+YZrSctwCJhK+3h3i4X990XvjJQ3Hmw==\n"
+ "-END CERTIFICATE-\n"
;
private static
[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 (fi
[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 location
[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] [Updated] (VELOCITY-367) Anakia throws NullPointerException if run under Maven with Custom Contexts
[ https://issues.apache.org/jira/browse/VELOCITY-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Wells updated VELOCITY-367: - Reporter: Henning Schmiedehausen (was: Henning Schmiedehausen) > Anakia throws NullPointerException if run under Maven with Custom Contexts > -- > > Key: VELOCITY-367 > URL: https://issues.apache.org/jira/browse/VELOCITY-367 > Project: Velocity > Issue Type: Bug > Components: Anakia >Affects Versions: 1.5 > Environment: Operating System: Linux > Platform: All >Reporter: Henning Schmiedehausen >Priority: Major > Attachments: ASF.LICENSE.NOT.GRANTED--anakia.patch > > > The AnakiaTask has the feature to use a custom context object. This is tested > in > the AnakiaTestCase. However, when running this test (and the AnakiaTask) under > Maven, it fails with a NullPointerException. The reason is that maven uses a > different sequence to initialize the AnakiaTask and Context objects and set > their properties. When running under ant, the setFile() method in the Context > object is called after setBaseDir() in the AnakiaTask, which allows setFile() > to > resolve the baseDir member. When running under maven, setBasedir() is called > after the Context object has been initialized thus using a null baseDir > element > when creating the contextFile element in Context. > When using an element outside the current working directory, this leads to > subContext.getContextDocument() returning null in line 378, thus resulting in > a > NullPointerException. > The attached patch adds checks for this condition and throws a BuildExeption. > It > also defers the creation of the contextDoc member of the context until it is > actually referenced. -- 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-966) RuntimeInstance.render throws null pointer exception when trying to render the same AST
[
https://issues.apache.org/jira/browse/VELOCITY-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex updated VELOCITY-966:
--
Description:
The objective is to use
*RuntimeInstance.parse* to get the parsed AST for some template and cache the
AST.
Then use *RuntimeInstance.render* multiple times to render the text.
It appears that in version 2.3 {*}RuntimeInstance.{*}{*}render{*} invokes the
Node.init call and at the end of the rendering clears the parser and tokens. On
the next attempt to render init fails with the NullPointerException because
tokens have been cleared.{*}{*}
So you can not call *RuntimeInstance.render* on the same AST several times
which seems to be the intent of this method...
was:
The objective is to use
*RuntimeInstance.parse* to get the parsed AST for some test and cache the AST.
Then use *RuntimeInstance.render* multiple times to render the text.
It appears that in version 2.3 {*}RuntimeInstance.{*}{*}render{*} invokes the
Node.init call and at the end of the rendering clears the parser and tokens. On
the next attempt to render init fails with the NullPointerException because
tokens have been cleared.{*}{*}
So you can not call *RuntimeInstance.render* on the same AST several times
which seems to be the intent of this method...
> RuntimeInstance.render throws null pointer exception when trying to render
> the same AST
>
>
> Key: VELOCITY-966
> URL: https://issues.apache.org/jira/browse/VELOCITY-966
> Project: Velocity
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Alex
>Priority: Major
>
> The objective is to use
> *RuntimeInstance.parse* to get the parsed AST for some template and cache the
> AST.
> Then use *RuntimeInstance.render* multiple times to render the text.
>
> It appears that in version 2.3 {*}RuntimeInstance.{*}{*}render{*} invokes the
> Node.init call and at the end of the rendering clears the parser and tokens.
> On the next attempt to render init fails with the NullPointerException
> because tokens have been cleared.{*}{*}
>
> So you can not call *RuntimeInstance.render* on the same AST several times
> which seems to be the intent of this method...
--
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-966) RuntimeInstance.render throws null pointer exception when trying to render the same AST
[
https://issues.apache.org/jira/browse/VELOCITY-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex updated VELOCITY-966:
--
Affects Version/s: 2.3
Description:
The objective is to use
*RuntimeInstance.parse* to get the parsed AST for some test and cache the AST.
Then use *RuntimeInstance.render* multiple times to render the text.
It appears that in version 2.3 {*}RuntimeInstance.{*}{*}render{*} invokes the
Node.init call and at the end of the rendering clears the parser and tokens. On
the next attempt to render init fails with the NullPointerException because
tokens have been cleared.{*}{*}
So you can not call *RuntimeInstance.render* on the same AST several times
which seems to be the intent of this method...
> RuntimeInstance.render throws null pointer exception when trying to render
> the same AST
>
>
> Key: VELOCITY-966
> URL: https://issues.apache.org/jira/browse/VELOCITY-966
> Project: Velocity
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Alex
>Priority: Major
>
> The objective is to use
> *RuntimeInstance.parse* to get the parsed AST for some test and cache the AST.
> Then use *RuntimeInstance.render* multiple times to render the text.
>
> It appears that in version 2.3 {*}RuntimeInstance.{*}{*}render{*} invokes the
> Node.init call and at the end of the rendering clears the parser and tokens.
> On the next attempt to render init fails with the NullPointerException
> because tokens have been cleared.{*}{*}
>
> So you can not call *RuntimeInstance.render* on the same AST several times
> which seems to be the intent of this method...
--
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-966) RuntimeInstance.render throws null pointer exception when trying to render the same AST
Alex created VELOCITY-966: - Summary: RuntimeInstance.render throws null pointer exception when trying to render the same AST Key: VELOCITY-966 URL: https://issues.apache.org/jira/browse/VELOCITY-966 Project: Velocity Issue Type: Bug Reporter: Alex -- 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] [Moved] (VELTOOLS-202) VelocityViewServlet extending from jakarta.servlet instead of javax.servlet
[ https://issues.apache.org/jira/browse/VELTOOLS-202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov moved VELOCITY-942 to VELTOOLS-202: -- Component/s: VelocityView (was: Engine) Key: VELTOOLS-202 (was: VELOCITY-942) Project: Velocity Tools (was: Velocity) > VelocityViewServlet extending from jakarta.servlet instead of javax.servlet > --- > > Key: VELTOOLS-202 > URL: https://issues.apache.org/jira/browse/VELTOOLS-202 > Project: Velocity Tools > Issue Type: New Feature > Components: VelocityView >Reporter: David Ruiz de Azua >Priority: Trivial > > To whom may concern, > Currently VelocityViewServlet extends from javax rather than jakarta. > Due the cutover from Java to Jakarta, *is there any plan to make Apache > Velocity compatible with Servlet 5.0?* > Not sure if there are any plans to make the transition to Jakarta namespace > and if there is any ETA for it. > [https://jakarta.ee/specifications/servlet/5.0/apidocs/jakarta/servlet/http/httpservlet] -- 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-965) Velocity 1.7 vs velocity 2.3: Getting thread synchronization issue
[
https://issues.apache.org/jira/browse/VELOCITY-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17725811#comment-17725811
]
Marinó A. Jónsson commented on VELOCITY-965:
* There is no need to share the Statement for fetching the timestamp as it just
returns a value and not a Reader - so this particular error is easily fixed
(the readLastModified method isn't even synchronized).
* However, according to the stackoverflow discussion it seems that if the same
Statement is executed twice the second query will close the previous ResultSet
- so this implementation is not thread-safe even though the getResourceReader
method is synchronized ... if two templates are being fetched at the same time
the second query could easily close the first ResultSet for the first query
before the Reader has finished reading.
> Velocity 1.7 vs velocity 2.3: Getting thread synchronization issue
> --
>
> Key: VELOCITY-965
> URL: https://issues.apache.org/jira/browse/VELOCITY-965
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Amrit
>Priority: Major
>
> Recently we migrated from Velocity 1.7 to Velocity 2.3. We see the below
> error intermittently which is a possible thread synchronization issue with
> Velocity Engine. The resultset is getting closed while another thread is
> making use of it.
> {noformat}
> 2023-04-15 10:36:33.472 ERROR [org.apache.velocity.loader.ds]
> {344} - DataSourceResourceLoader: database problem while getting timestamp of
> 'xyz_abc':
> java.sql.SQLException: Closed Resultset: next
> at
> oracle.jdbc.driver.InsensitiveScrollableResultSet.ensureOpen(InsensitiveScrollableResultSet.java:109)
> ~[ojdbc8.jar:12.2.0.1.0]
> at
> oracle.jdbc.driver.InsensitiveScrollableResultSet.next(InsensitiveScrollableResultSet.java:398)
> ~[ojdbc8.jar:12.2.0.1.0]
> at
> weblogic.jdbc.wrapper.ResultSet_oracle_jdbc_driver_ForwardOnlyResultSet.next(Unknown
> Source) ~[CodeGenerator.class:12.2.1.3]
> at
> org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader.readLastModified(DataSourceResourceLoader.java:326)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader.getLastModified(DataSourceResourceLoader.java:240)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:446)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:346)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1677)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1656)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.app.VelocityEngine.getTemplate(VelocityEngine.java:314)
> ~[velocity-engine-core-2.3.jar:2.3]
> {noformat}
> Reference:
> https://stackoverflow.com/questions/2794167/is-resultset-thread-safe
--
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-965) Velocity 1.7 vs velocity 2.3: Getting thread synchronization issue
[
https://issues.apache.org/jira/browse/VELOCITY-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17725784#comment-17725784
]
Marinó A. Jónsson commented on VELOCITY-965:
PR is a "Pull Request" for the git repository (see
[https://github.com/apache/velocity-engine]) ... if you clone the project and
fix the issue yourself, you can put it in a separate branch, push it to the git
repository, and then create a pull request for it to be merged with the master
branch.
> Velocity 1.7 vs velocity 2.3: Getting thread synchronization issue
> --
>
> Key: VELOCITY-965
> URL: https://issues.apache.org/jira/browse/VELOCITY-965
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Amrit
>Priority: Major
>
> Recently we migrated from Velocity 1.7 to Velocity 2.3. We see the below
> error intermittently which is a possible thread synchronization issue with
> Velocity Engine. The resultset is getting closed while another thread is
> making use of it.
> {noformat}
> 2023-04-15 10:36:33.472 ERROR [org.apache.velocity.loader.ds]
> {344} - DataSourceResourceLoader: database problem while getting timestamp of
> 'xyz_abc':
> java.sql.SQLException: Closed Resultset: next
> at
> oracle.jdbc.driver.InsensitiveScrollableResultSet.ensureOpen(InsensitiveScrollableResultSet.java:109)
> ~[ojdbc8.jar:12.2.0.1.0]
> at
> oracle.jdbc.driver.InsensitiveScrollableResultSet.next(InsensitiveScrollableResultSet.java:398)
> ~[ojdbc8.jar:12.2.0.1.0]
> at
> weblogic.jdbc.wrapper.ResultSet_oracle_jdbc_driver_ForwardOnlyResultSet.next(Unknown
> Source) ~[CodeGenerator.class:12.2.1.3]
> at
> org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader.readLastModified(DataSourceResourceLoader.java:326)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader.getLastModified(DataSourceResourceLoader.java:240)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:446)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:346)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1677)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1656)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.app.VelocityEngine.getTemplate(VelocityEngine.java:314)
> ~[velocity-engine-core-2.3.jar:2.3]
> {noformat}
> Reference:
> https://stackoverflow.com/questions/2794167/is-resultset-thread-safe
--
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-965) Velocity 1.7 vs velocity 2.3: Getting thread synchronization issue
[
https://issues.apache.org/jira/browse/VELOCITY-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17725755#comment-17725755
]
Amrit commented on VELOCITY-965:
Thanks for the comment. Sorry what do you mean by PR here?
> Velocity 1.7 vs velocity 2.3: Getting thread synchronization issue
> --
>
> Key: VELOCITY-965
> URL: https://issues.apache.org/jira/browse/VELOCITY-965
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Amrit
>Priority: Major
>
> Recently we migrated from Velocity 1.7 to Velocity 2.3. We see the below
> error intermittently which is a possible thread synchronization issue with
> Velocity Engine. The resultset is getting closed while another thread is
> making use of it.
> {noformat}
> 2023-04-15 10:36:33.472 ERROR [org.apache.velocity.loader.ds]
> {344} - DataSourceResourceLoader: database problem while getting timestamp of
> 'xyz_abc':
> java.sql.SQLException: Closed Resultset: next
> at
> oracle.jdbc.driver.InsensitiveScrollableResultSet.ensureOpen(InsensitiveScrollableResultSet.java:109)
> ~[ojdbc8.jar:12.2.0.1.0]
> at
> oracle.jdbc.driver.InsensitiveScrollableResultSet.next(InsensitiveScrollableResultSet.java:398)
> ~[ojdbc8.jar:12.2.0.1.0]
> at
> weblogic.jdbc.wrapper.ResultSet_oracle_jdbc_driver_ForwardOnlyResultSet.next(Unknown
> Source) ~[CodeGenerator.class:12.2.1.3]
> at
> org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader.readLastModified(DataSourceResourceLoader.java:326)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader.getLastModified(DataSourceResourceLoader.java:240)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:446)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:346)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1677)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1656)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.app.VelocityEngine.getTemplate(VelocityEngine.java:314)
> ~[velocity-engine-core-2.3.jar:2.3]
> {noformat}
> Reference:
> https://stackoverflow.com/questions/2794167/is-resultset-thread-safe
--
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-965) Velocity 1.7 vs velocity 2.3: Getting thread synchronization issue
[
https://issues.apache.org/jira/browse/VELOCITY-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17725744#comment-17725744
]
Michael Osipov commented on VELOCITY-965:
-
This is open source, you can provide a PR to address the issue. Moreover, you
cannot expect anything since this is open source. If you want progress, do
something.
> Velocity 1.7 vs velocity 2.3: Getting thread synchronization issue
> --
>
> Key: VELOCITY-965
> URL: https://issues.apache.org/jira/browse/VELOCITY-965
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Amrit
>Priority: Major
>
> Recently we migrated from Velocity 1.7 to Velocity 2.3. We see the below
> error intermittently which is a possible thread synchronization issue with
> Velocity Engine. The resultset is getting closed while another thread is
> making use of it.
> {noformat}
> 2023-04-15 10:36:33.472 ERROR [org.apache.velocity.loader.ds]
> {344} - DataSourceResourceLoader: database problem while getting timestamp of
> 'xyz_abc':
> java.sql.SQLException: Closed Resultset: next
> at
> oracle.jdbc.driver.InsensitiveScrollableResultSet.ensureOpen(InsensitiveScrollableResultSet.java:109)
> ~[ojdbc8.jar:12.2.0.1.0]
> at
> oracle.jdbc.driver.InsensitiveScrollableResultSet.next(InsensitiveScrollableResultSet.java:398)
> ~[ojdbc8.jar:12.2.0.1.0]
> at
> weblogic.jdbc.wrapper.ResultSet_oracle_jdbc_driver_ForwardOnlyResultSet.next(Unknown
> Source) ~[CodeGenerator.class:12.2.1.3]
> at
> org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader.readLastModified(DataSourceResourceLoader.java:326)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader.getLastModified(DataSourceResourceLoader.java:240)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:446)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:346)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1677)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1656)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.app.VelocityEngine.getTemplate(VelocityEngine.java:314)
> ~[velocity-engine-core-2.3.jar:2.3]
> {noformat}
> Reference:
> https://stackoverflow.com/questions/2794167/is-resultset-thread-safe
--
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-965) Velocity 1.7 vs velocity 2.3: Getting thread synchronization issue
[
https://issues.apache.org/jira/browse/VELOCITY-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17725731#comment-17725731
]
Amrit edited comment on VELOCITY-965 at 5/24/23 10:12 AM:
--
Generally what is the process to fix such issues for the Velocity project?
Would someone be looking into this issue and can we expect a fix anytime?
was (Author: JIRAUSER299929):
Generally what is process to fix such issues for the Velocity project? Would
someone be looking into this issue and can we expect a fix anytime?
> Velocity 1.7 vs velocity 2.3: Getting thread synchronization issue
> --
>
> Key: VELOCITY-965
> URL: https://issues.apache.org/jira/browse/VELOCITY-965
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Amrit
>Priority: Major
>
> Recently we migrated from Velocity 1.7 to Velocity 2.3. We see the below
> error intermittently which is a possible thread synchronization issue with
> Velocity Engine. The resultset is getting closed while another thread is
> making use of it.
> {noformat}
> 2023-04-15 10:36:33.472 ERROR [org.apache.velocity.loader.ds]
> {344} - DataSourceResourceLoader: database problem while getting timestamp of
> 'xyz_abc':
> java.sql.SQLException: Closed Resultset: next
> at
> oracle.jdbc.driver.InsensitiveScrollableResultSet.ensureOpen(InsensitiveScrollableResultSet.java:109)
> ~[ojdbc8.jar:12.2.0.1.0]
> at
> oracle.jdbc.driver.InsensitiveScrollableResultSet.next(InsensitiveScrollableResultSet.java:398)
> ~[ojdbc8.jar:12.2.0.1.0]
> at
> weblogic.jdbc.wrapper.ResultSet_oracle_jdbc_driver_ForwardOnlyResultSet.next(Unknown
> Source) ~[CodeGenerator.class:12.2.1.3]
> at
> org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader.readLastModified(DataSourceResourceLoader.java:326)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader.getLastModified(DataSourceResourceLoader.java:240)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:446)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:346)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1677)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1656)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.app.VelocityEngine.getTemplate(VelocityEngine.java:314)
> ~[velocity-engine-core-2.3.jar:2.3]
> {noformat}
> Reference:
> https://stackoverflow.com/questions/2794167/is-resultset-thread-safe
--
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-965) Velocity 1.7 vs velocity 2.3: Getting thread synchronization issue
[
https://issues.apache.org/jira/browse/VELOCITY-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17725731#comment-17725731
]
Amrit commented on VELOCITY-965:
Generally what is process to fix such issues for the Velocity project? Would
someone be looking into this issue and can we expect a fix anytime?
> Velocity 1.7 vs velocity 2.3: Getting thread synchronization issue
> --
>
> Key: VELOCITY-965
> URL: https://issues.apache.org/jira/browse/VELOCITY-965
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Amrit
>Priority: Major
>
> Recently we migrated from Velocity 1.7 to Velocity 2.3. We see the below
> error intermittently which is a possible thread synchronization issue with
> Velocity Engine. The resultset is getting closed while another thread is
> making use of it.
> {noformat}
> 2023-04-15 10:36:33.472 ERROR [org.apache.velocity.loader.ds]
> {344} - DataSourceResourceLoader: database problem while getting timestamp of
> 'xyz_abc':
> java.sql.SQLException: Closed Resultset: next
> at
> oracle.jdbc.driver.InsensitiveScrollableResultSet.ensureOpen(InsensitiveScrollableResultSet.java:109)
> ~[ojdbc8.jar:12.2.0.1.0]
> at
> oracle.jdbc.driver.InsensitiveScrollableResultSet.next(InsensitiveScrollableResultSet.java:398)
> ~[ojdbc8.jar:12.2.0.1.0]
> at
> weblogic.jdbc.wrapper.ResultSet_oracle_jdbc_driver_ForwardOnlyResultSet.next(Unknown
> Source) ~[CodeGenerator.class:12.2.1.3]
> at
> org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader.readLastModified(DataSourceResourceLoader.java:326)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader.getLastModified(DataSourceResourceLoader.java:240)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:446)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:346)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1677)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1656)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.app.VelocityEngine.getTemplate(VelocityEngine.java:314)
> ~[velocity-engine-core-2.3.jar:2.3]
> {noformat}
> Reference:
> https://stackoverflow.com/questions/2794167/is-resultset-thread-safe
--
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-965) Velocity 1.7 vs velocity 2.3: Getting thread synchronization issue
[
https://issues.apache.org/jira/browse/VELOCITY-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17713740#comment-17713740
]
Michael Osipov commented on VELOCITY-965:
-
I took a brief look at the class. Something looks fishy to me: The class is a
singleton, yet it shares the connection and both prepared statements outside of
the scope of {{public synchronized Reader getResourceReader()}}. This doesn't
feel right to me.
> Velocity 1.7 vs velocity 2.3: Getting thread synchronization issue
> --
>
> Key: VELOCITY-965
> URL: https://issues.apache.org/jira/browse/VELOCITY-965
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Amrit
>Priority: Major
>
> Recently we migrated from Velocity 1.7 to Velocity 2.3. We see the below
> error intermittently which is a possible thread synchronization issue with
> Velocity Engine. The resultset is getting closed while another thread is
> making use of it.
> {noformat}
> 2023-04-15 10:36:33.472 ERROR [org.apache.velocity.loader.ds]
> {344} - DataSourceResourceLoader: database problem while getting timestamp of
> 'xyz_abc':
> java.sql.SQLException: Closed Resultset: next
> at
> oracle.jdbc.driver.InsensitiveScrollableResultSet.ensureOpen(InsensitiveScrollableResultSet.java:109)
> ~[ojdbc8.jar:12.2.0.1.0]
> at
> oracle.jdbc.driver.InsensitiveScrollableResultSet.next(InsensitiveScrollableResultSet.java:398)
> ~[ojdbc8.jar:12.2.0.1.0]
> at
> weblogic.jdbc.wrapper.ResultSet_oracle_jdbc_driver_ForwardOnlyResultSet.next(Unknown
> Source) ~[CodeGenerator.class:12.2.1.3]
> at
> org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader.readLastModified(DataSourceResourceLoader.java:326)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader.getLastModified(DataSourceResourceLoader.java:240)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:446)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:346)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1677)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1656)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.app.VelocityEngine.getTemplate(VelocityEngine.java:314)
> ~[velocity-engine-core-2.3.jar:2.3]
> {noformat}
> Reference:
> https://stackoverflow.com/questions/2794167/is-resultset-thread-safe
--
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-965) Velocity 1.7 vs velocity 2.3: Getting thread synchronization issue
[
https://issues.apache.org/jira/browse/VELOCITY-965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated VELOCITY-965:
Description:
Recently we migrated from Velocity 1.7 to Velocity 2.3. We see the below error
intermittently which is a possible thread synchronization issue with Velocity
Engine. The resultset is getting closed while another thread is making use of
it.
{noformat}
2023-04-15 10:36:33.472 ERROR [org.apache.velocity.loader.ds] \{344} -
DataSourceResourceLoader: database problem while getting timestamp of
'xyz_abc':
java.sql.SQLException: Closed Resultset: next
at
oracle.jdbc.driver.InsensitiveScrollableResultSet.ensureOpen(InsensitiveScrollableResultSet.java:109)
~[ojdbc8.jar:12.2.0.1.0]
at
oracle.jdbc.driver.InsensitiveScrollableResultSet.next(InsensitiveScrollableResultSet.java:398)
~[ojdbc8.jar:12.2.0.1.0]
at
weblogic.jdbc.wrapper.ResultSet_oracle_jdbc_driver_ForwardOnlyResultSet.next(Unknown
Source) ~[CodeGenerator.class:12.2.1.3]
at
org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader.readLastModified(DataSourceResourceLoader.java:326)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader.getLastModified(DataSourceResourceLoader.java:240)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:446)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:346)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1677)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1656)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.app.VelocityEngine.getTemplate(VelocityEngine.java:314)
~[velocity-engine-core-2.3.jar:2.3]
{noformat}
Reference:
https://stackoverflow.com/questions/2794167/is-resultset-thread-safe
was:
Recently we migrated from Velocity 1.7 to Velocity 2.3. We see the below error
intermittently which is a possible thread synchronization issue with Velocity
Engine. The resultset is getting closed while another thread is making use of
it.
2023-04-15 10:36:33.472 ERROR [org.apache.velocity.loader.ds] \{344} -
DataSourceResourceLoader: database problem while getting timestamp of
'xyz_abc':
java.sql.SQLException: Closed Resultset: next
at
oracle.jdbc.driver.InsensitiveScrollableResultSet.ensureOpen(InsensitiveScrollableResultSet.java:109)
~[ojdbc8.jar:12.2.0.1.0]
at
oracle.jdbc.driver.InsensitiveScrollableResultSet.next(InsensitiveScrollableResultSet.java:398)
~[ojdbc8.jar:12.2.0.1.0]
at
weblogic.jdbc.wrapper.ResultSet_oracle_jdbc_driver_ForwardOnlyResultSet.next(Unknown
Source) ~[CodeGenerator.class:12.2.1.3]
at
org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader.readLastModified(DataSourceResourceLoader.java:326)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader.getLastModified(DataSourceResourceLoader.java:240)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:446)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:346)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1677)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1656)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.app.VelocityEngine.getTemplate(VelocityEngine.java:314)
~[velocity-engine-core-2.3.jar:2.3]
Reference:
https://stackoverflow.com/questions/2794167/is-resultset-thread-safe
> Velocity 1.7 vs velocity 2.3: Getting thread synchronization issue
> --
>
> Key: VELOCITY-965
> URL: https://issues.apache.org/jira/browse/VELOCITY-965
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Amrit
>Priority: Major
>
> Recently we migrated from Velocity 1.7 to Velocity 2.3. We see the below
> error intermittently which is a possible thread synchronization issue with
> Velocity Engine. The resultset is getting closed while another thread is
> making use of it.
> {noformat}
> 2023-04-15 10:36:33.472 ERROR [org.apache.velocity.loader.ds] \{344} -
> DataSourceResourceLoader: datab
[jira] [Updated] (VELOCITY-965) Velocity 1.7 vs velocity 2.3: Getting thread synchronization issue
[
https://issues.apache.org/jira/browse/VELOCITY-965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated VELOCITY-965:
Description:
Recently we migrated from Velocity 1.7 to Velocity 2.3. We see the below error
intermittently which is a possible thread synchronization issue with Velocity
Engine. The resultset is getting closed while another thread is making use of
it.
{noformat}
2023-04-15 10:36:33.472 ERROR [org.apache.velocity.loader.ds]
{344} - DataSourceResourceLoader: database problem while getting timestamp of
'xyz_abc':
java.sql.SQLException: Closed Resultset: next
at
oracle.jdbc.driver.InsensitiveScrollableResultSet.ensureOpen(InsensitiveScrollableResultSet.java:109)
~[ojdbc8.jar:12.2.0.1.0]
at
oracle.jdbc.driver.InsensitiveScrollableResultSet.next(InsensitiveScrollableResultSet.java:398)
~[ojdbc8.jar:12.2.0.1.0]
at
weblogic.jdbc.wrapper.ResultSet_oracle_jdbc_driver_ForwardOnlyResultSet.next(Unknown
Source) ~[CodeGenerator.class:12.2.1.3]
at
org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader.readLastModified(DataSourceResourceLoader.java:326)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader.getLastModified(DataSourceResourceLoader.java:240)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:446)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:346)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1677)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1656)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.app.VelocityEngine.getTemplate(VelocityEngine.java:314)
~[velocity-engine-core-2.3.jar:2.3]
{noformat}
Reference:
https://stackoverflow.com/questions/2794167/is-resultset-thread-safe
was:
Recently we migrated from Velocity 1.7 to Velocity 2.3. We see the below error
intermittently which is a possible thread synchronization issue with Velocity
Engine. The resultset is getting closed while another thread is making use of
it.
{noformat}
2023-04-15 10:36:33.472 ERROR [org.apache.velocity.loader.ds] \{344} -
DataSourceResourceLoader: database problem while getting timestamp of
'xyz_abc':
java.sql.SQLException: Closed Resultset: next
at
oracle.jdbc.driver.InsensitiveScrollableResultSet.ensureOpen(InsensitiveScrollableResultSet.java:109)
~[ojdbc8.jar:12.2.0.1.0]
at
oracle.jdbc.driver.InsensitiveScrollableResultSet.next(InsensitiveScrollableResultSet.java:398)
~[ojdbc8.jar:12.2.0.1.0]
at
weblogic.jdbc.wrapper.ResultSet_oracle_jdbc_driver_ForwardOnlyResultSet.next(Unknown
Source) ~[CodeGenerator.class:12.2.1.3]
at
org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader.readLastModified(DataSourceResourceLoader.java:326)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader.getLastModified(DataSourceResourceLoader.java:240)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:446)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:346)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1677)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1656)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.app.VelocityEngine.getTemplate(VelocityEngine.java:314)
~[velocity-engine-core-2.3.jar:2.3]
{noformat}
Reference:
https://stackoverflow.com/questions/2794167/is-resultset-thread-safe
> Velocity 1.7 vs velocity 2.3: Getting thread synchronization issue
> --
>
> Key: VELOCITY-965
> URL: https://issues.apache.org/jira/browse/VELOCITY-965
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Amrit
>Priority: Major
>
> Recently we migrated from Velocity 1.7 to Velocity 2.3. We see the below
> error intermittently which is a possible thread synchronization issue with
> Velocity Engine. The resultset is getting closed while another thread is
> making use of it.
> {noformat}
> 2023-04-15 10:36:33.472 ERROR [org.apache.velocity.loader.ds]
> {344} - Data
[jira] [Created] (VELOCITY-965) Velocity 1.7 vs velocity 2.3: Getting thread synchronization issue
Amrit created VELOCITY-965:
--
Summary: Velocity 1.7 vs velocity 2.3: Getting thread
synchronization issue
Key: VELOCITY-965
URL: https://issues.apache.org/jira/browse/VELOCITY-965
Project: Velocity
Issue Type: Bug
Components: Engine
Affects Versions: 2.3
Reporter: Amrit
Recently we migrated from Velocity 1.7 to Velocity 2.3. We see the below error
intermittently which is a possible thread synchronization issue with Velocity
Engine. The resultset is getting closed while another thread is making use of
it.
2023-04-15 10:36:33.472 ERROR [org.apache.velocity.loader.ds] \{344} -
DataSourceResourceLoader: database problem while getting timestamp of
'xyz_abc':
java.sql.SQLException: Closed Resultset: next
at
oracle.jdbc.driver.InsensitiveScrollableResultSet.ensureOpen(InsensitiveScrollableResultSet.java:109)
~[ojdbc8.jar:12.2.0.1.0]
at
oracle.jdbc.driver.InsensitiveScrollableResultSet.next(InsensitiveScrollableResultSet.java:398)
~[ojdbc8.jar:12.2.0.1.0]
at
weblogic.jdbc.wrapper.ResultSet_oracle_jdbc_driver_ForwardOnlyResultSet.next(Unknown
Source) ~[CodeGenerator.class:12.2.1.3]
at
org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader.readLastModified(DataSourceResourceLoader.java:326)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader.getLastModified(DataSourceResourceLoader.java:240)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:446)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:346)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1677)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1656)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.app.VelocityEngine.getTemplate(VelocityEngine.java:314)
~[velocity-engine-core-2.3.jar:2.3]
Reference:
https://stackoverflow.com/questions/2794167/is-resultset-thread-safe
--
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&focusedCommentId=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&focusedCommentId=17710993#comment-17710993
]
Thomas Mortagne commented on VELOCITY-952:
--
{quote}
bq. respecting the method return type
Carrying this information around with the object sounds like a complex thing to
change (but maybe not, I don't know the Velocity AST very well), but I agree
it's probably the most accurate.
{quote}
So I finally did some digging on what it would take to implement this idea, and
it's indeed not trivial. From what I understood, the problem is that here is no
way to associate metadata to a value in the context right now, so all the APIs
which manipulate the value of a variable don't have any way to pass/return more
info about this value (thinking especially about associating a Type with the
value in the Context and how to return a Type along with the value returned by
ASTMethod#execute.
I started by refactoring a bit {{org.apache.velocity.context.Context}} to
support associating metadata to an entry without breaking existing API, but
then the number of things to change in pretty critical places to take this into
account is a bit overwhelming for me and a huge challenge in terms of retro
compatibly without really knowing if that's really the direction that you guys
want to take.
Problem is that this bug makes pretty much impossible to say that XWiki
supports Java 17 because of the many unforeseen IllegalAccessException failures
you can end up with depending on which apparently standard Java API you are
manipulating in a script. So for now my plan is to workaround this with an
uberspector on XWiki side doing what I initially proposed: try to find the
lowest overwritten Method (which, I agree, is not the best and not something I
would recommend on standard Velocity side compared to the "carry the return
type around with the value" idea).
> Velocity is calling the "wrong" method
> --
>
> Key: VELOCITY-952
> URL: https://issues.apache.org/jira/browse/VELOCITY-952
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Thomas Mortagne
>Priority: Major
>
> OK, the title is maybe a bit harsh, but it catches the eyes :)
> At XWiki we recently started testing on Java 17 to see if there is any
> problem which leaded us to add things like {{--add-opens
> java.base/java.util=ALL-UNNAMED}} but Velocity happen to be the source of
> another problem related to the new module world.
> When doing something like {{$datetool.timeZone.getOffset(0)}} ($datetool
> being the org.apache.velocity.tools.generic.DateTool) we get the following
> error:
> {noformat}
> ...
> Caused by: java.lang.IllegalAccessException: class
> org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl cannot
> access class sun.util.calendar.ZoneInfo (in module java.base) because module
> java.base does not export sun.util.calendar to unnamed module @7ca16adc
> at
> java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:392)
> at
> java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674)
> at java.base/java.lang.reflect.Method.invoke(Method.java:560)
> at
> org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:571)
> at
> org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:554)
> at
> org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:221)
> ... 199 more
> {noformat}
> The reason is that while the developer intent/expectation was to call
> "java.util.TimeZone#getOffset(0)" what Velocity really called from JVM point
> of view is "sun.util.calendar.ZoneInfo.getOffset(0)" directly.
> That's because Velocity is doing (I assume, since I did not check the exact
> code) the equivalent of:
> {noformat}
> java.util.TimeZone.getDefault().getClass().getMethod("getOffset",
> long.class).invoke(TimeZone.getDefault(), 0);
> {noformat}
> which is itself the equivalent of:
> {noformat}
> sun.util.calendar.ZoneInfo.class.getMethod("getOffset",
> long.class).invoke(TimeZone.getDefault(), 0);
> {noformat}
> I guess the only way to fix this would be to track down the lowest overridden
> Method (I agree, it might not always be easy to choose between two interfaces
> declaring a method with the same signature, but choosing the first one we
> find from the same hierarchy level is still better than nothing) and call
> that one inst
[jira] [Assigned] (VELTOOLS-201) Document $esc.unicode() in Javadoc and page listing
[
https://issues.apache.org/jira/browse/VELTOOLS-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned VELTOOLS-201:
---
Assignee: (was: Michael Osipov)
> Document $esc.unicode() in Javadoc and page listing
> ---
>
> Key: VELTOOLS-201
> URL: https://issues.apache.org/jira/browse/VELTOOLS-201
> Project: Velocity Tools
> Issue Type: Task
> Components: GenericTools
>Affects Versions: 3.1
>Reporter: Michael Osipov
>Priority: Major
>
> No example for {{$esc.unicode()}} is provided here:
> https://velocity.apache.org/tools/3.1/apidocs/org/apache/velocity/tools/generic/EscapeTool.html
> nor is it mentioned here:
> https://velocity.apache.org/tools/3.1/tools-summary.html#EscapeTool
> Took me some time to find out have I can type in {{\uXXXX}}.
--
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] (VELTOOLS-201) Document $esc.unicode() in Javadoc and page listing
Michael Osipov created VELTOOLS-201:
---
Summary: Document $esc.unicode() in Javadoc and page listing
Key: VELTOOLS-201
URL: https://issues.apache.org/jira/browse/VELTOOLS-201
Project: Velocity Tools
Issue Type: Task
Components: GenericTools
Affects Versions: 3.1
Reporter: Michael Osipov
Assignee: Michael Osipov
No example for {{$esc.unicode()}} is provided here:
https://velocity.apache.org/tools/3.1/apidocs/org/apache/velocity/tools/generic/EscapeTool.html
nor is it mentioned here:
https://velocity.apache.org/tools/3.1/tools-summary.html#EscapeTool
Took me some time to find out have I can type in {{\u}}.
--
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] [Closed] (VELOCITY-963) Incompatible API changes in 2.x
[ https://issues.apache.org/jira/browse/VELOCITY-963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson closed VELOCITY-963. --- Assignee: Claude Brisson Resolution: Won't Fix > Incompatible API changes in 2.x > --- > > Key: VELOCITY-963 > URL: https://issues.apache.org/jira/browse/VELOCITY-963 > Project: Velocity > Issue Type: Bug > Components: Documentation >Affects Versions: 2.0, 2.1, 2.2, 2.3 >Reporter: Éamonn McManus >Assignee: Claude Brisson >Priority: Minor > > I recently tried porting a large amount of Velocity client code from 1.7 to > 2.3 and discovered a number of incompatible API changes. Some of these were > probably unavoidable but at least one could be fixed to ease this kind of > migration. > * The three RuntimeInstance.parse methods from 1.7 were replaced by a single > RuntimeInstance.parse(Reader, Template) method. I found that I could work > around this by changing this: > SimpleNode node = runtimeInstance.parse(reader, resourceName); > to this: > Template template = new Template(); > template.setName(resourceName); > SimpleNode node = runtimeInstance.parse(reader, template); > But it would be convenient for people migrating if the old overloads were > restored. (This might not be the best way to parse a template, but it was > certainly quite widely used in the code I was porting.) > * VelocityContext(Map) becomes VelocityContext(Map). Some of > the code was passing a Map or a Map. That would > work if the argument type were Map, but I don't think that would > be correct since I believe the Map can be updated by #set directives. So > perhaps document this more explicitly. > * This abstract method in ResourceLoader > InputStream getResourceStream(String source) > becomes > Reader getResourceReader(String source, String encoding) > I'm not sure there would have been a good way to allow subclasses of > ResourceLoader to continue to work without change, and this change _is_ > documented in the [migration > guide|https://velocity.apache.org/engine/2.0/upgrading.html#behavior-api-changes] > so there's probably nothing further to do here. > * Nearly all the methods in StringUtils have been deleted, and that's not > mentioned in the migration guide. -- 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-963) Incompatible API changes in 2.x
[ https://issues.apache.org/jira/browse/VELOCITY-963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17705088#comment-17705088 ] Claude Brisson commented on VELOCITY-963: - Point #3 is already documented, as stated by the reporter. Points #1 and #4 concern code entry points that should only be internal (too bad they're not) ; and the fix isn't difficult. For point #2: > VelocityContext(Map) becomes VelocityContext(Map). Some of > the code was passing a Map or a Map. That would > work if the argument type were Map, but I don't think that would > be correct since I believe the Map can be updated by #set directives. So > perhaps document this more explicitly. Because of type erasure, we cannot add a deprecated constructor taking a Map. So I don't see an easy fix, other than fixing the calling code. Yes, that's legitimate with the major version change. > Incompatible API changes in 2.x > --- > > Key: VELOCITY-963 > URL: https://issues.apache.org/jira/browse/VELOCITY-963 > Project: Velocity > Issue Type: Bug > Components: Documentation >Affects Versions: 2.0, 2.1, 2.2, 2.3 >Reporter: Éamonn McManus >Priority: Minor > > I recently tried porting a large amount of Velocity client code from 1.7 to > 2.3 and discovered a number of incompatible API changes. Some of these were > probably unavoidable but at least one could be fixed to ease this kind of > migration. > * The three RuntimeInstance.parse methods from 1.7 were replaced by a single > RuntimeInstance.parse(Reader, Template) method. I found that I could work > around this by changing this: > SimpleNode node = runtimeInstance.parse(reader, resourceName); > to this: > Template template = new Template(); > template.setName(resourceName); > SimpleNode node = runtimeInstance.parse(reader, template); > But it would be convenient for people migrating if the old overloads were > restored. (This might not be the best way to parse a template, but it was > certainly quite widely used in the code I was porting.) > * VelocityContext(Map) becomes VelocityContext(Map). Some of > the code was passing a Map or a Map. That would > work if the argument type were Map, but I don't think that would > be correct since I believe the Map can be updated by #set directives. So > perhaps document this more explicitly. > * This abstract method in ResourceLoader > InputStream getResourceStream(String source) > becomes > Reader getResourceReader(String source, String encoding) > I'm not sure there would have been a good way to allow subclasses of > ResourceLoader to continue to work without change, and this change _is_ > documented in the [migration > guide|https://velocity.apache.org/engine/2.0/upgrading.html#behavior-api-changes] > so there's probably nothing further to do here. > * Nearly all the methods in StringUtils have been deleted, and that's not > mentioned in the migration guide. -- 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-964) Allow formal notation for block macros
[
https://issues.apache.org/jira/browse/VELOCITY-964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson updated VELOCITY-964:
Affects Version/s: 2.3
> Allow formal notation for block macros
> --
>
> Key: VELOCITY-964
> URL: https://issues.apache.org/jira/browse/VELOCITY-964
> Project: Velocity
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Claude Brisson
>Priority: Minor
>
> The syntax #@\{test} is not functional.
>
--
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-964) Allow formal notation for block macros
[
https://issues.apache.org/jira/browse/VELOCITY-964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson updated VELOCITY-964:
Component/s: Engine
> Allow formal notation for block macros
> --
>
> Key: VELOCITY-964
> URL: https://issues.apache.org/jira/browse/VELOCITY-964
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Claude Brisson
>Priority: Minor
>
> The syntax #@\{test} is not functional.
>
--
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] [Assigned] (VELOCITY-964) Allow formal notation for block macros
[
https://issues.apache.org/jira/browse/VELOCITY-964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson reassigned VELOCITY-964:
---
Assignee: Claude Brisson
> Allow formal notation for block macros
> --
>
> Key: VELOCITY-964
> URL: https://issues.apache.org/jira/browse/VELOCITY-964
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Claude Brisson
>Assignee: Claude Brisson
>Priority: Minor
>
> The syntax #@\{test} is not functional.
>
--
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-964) Allow formal notation for block macros
[
https://issues.apache.org/jira/browse/VELOCITY-964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson updated VELOCITY-964:
Description:
The syntax #@\{test} is not functional.
> Allow formal notation for block macros
> --
>
> Key: VELOCITY-964
> URL: https://issues.apache.org/jira/browse/VELOCITY-964
> Project: Velocity
> Issue Type: Bug
>Reporter: Claude Brisson
>Priority: Minor
>
> The syntax #@\{test} is not functional.
>
--
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-964) Allow formal notation for block macros
[ https://issues.apache.org/jira/browse/VELOCITY-964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson updated VELOCITY-964: Priority: Minor (was: Major) > Allow formal notation for block macros > -- > > Key: VELOCITY-964 > URL: https://issues.apache.org/jira/browse/VELOCITY-964 > Project: Velocity > Issue Type: Bug >Reporter: Claude Brisson >Priority: Minor > -- 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-964) Allow formal notation for block macros
Claude Brisson created VELOCITY-964: --- Summary: Allow formal notation for block macros Key: VELOCITY-964 URL: https://issues.apache.org/jira/browse/VELOCITY-964 Project: Velocity Issue Type: Bug Reporter: Claude Brisson -- 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-940) bodyContent in nested macros called without @ should be unset
[
https://issues.apache.org/jira/browse/VELOCITY-940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17705081#comment-17705081
]
Claude Brisson commented on VELOCITY-940:
-
PS: I open another issue for #@\{test} and #\{@test} (to be consistent, it
should be #@\{test}).
> bodyContent in nested macros called without @ should be unset
> -
>
> Key: VELOCITY-940
> URL: https://issues.apache.org/jira/browse/VELOCITY-940
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 1.7.x, 2.3
>Reporter: Willow Nice
>Assignee: Claude Brisson
>Priority: Minor
> Fix For: 2.4
>
>
> Hi! First ever maybe bug report (pls be gentle).
>
> {{#macro(test $label)Something $!label $!bodyContent#\{end}}}
> {{#@test('First')}}{{#test('Second')}}{{#end}}
>
> ends up a recurring mess because $bodyContent seems to be still defined when
> calling the inner macro without a block. I propose (perleeze) that it should
> always be unset when calling a macro without a block. It's fine if you always
> call with @ and supply an empty block, or unset it manually before the second
> call
> p.s.
> #@\{test} or #\{@test} doesn't work either
>
--
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] [Resolved] (VELOCITY-940) bodyContent in nested macros called without @ should be unset
[
https://issues.apache.org/jira/browse/VELOCITY-940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson resolved VELOCITY-940.
-
Fix Version/s: 2.4
Assignee: Claude Brisson
Resolution: Fixed
> bodyContent in nested macros called without @ should be unset
> -
>
> Key: VELOCITY-940
> URL: https://issues.apache.org/jira/browse/VELOCITY-940
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 1.7.x, 2.3
>Reporter: Willow Nice
>Assignee: Claude Brisson
>Priority: Minor
> Fix For: 2.4
>
>
> Hi! First ever maybe bug report (pls be gentle).
>
> {{#macro(test $label)Something $!label $!bodyContent#\{end}}}
> {{#@test('First')}}{{#test('Second')}}{{#end}}
>
> ends up a recurring mess because $bodyContent seems to be still defined when
> calling the inner macro without a block. I propose (perleeze) that it should
> always be unset when calling a macro without a block. It's fine if you always
> call with @ and supply an empty block, or unset it manually before the second
> call
> p.s.
> #@\{test} or #\{@test} doesn't work either
>
--
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-940) bodyContent in nested macros called without @ should be unset
[
https://issues.apache.org/jira/browse/VELOCITY-940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17705080#comment-17705080
]
Claude Brisson commented on VELOCITY-940:
-
Velocimacros do support recursion. But there was a specific bug whenever using
a non-block call inside a block. Fixed in 2.4.
> Probably related, if you call a #@macro from inside another #@macro, the
> $bodyContent gets trashed, as in it doesn't seem to get restored when the
> inner macro finishes.
Not reproduced. But one thing to note: if you alter the content of $bodyContent
with a #set directive, the initial value won't be restored. This is by design.
> bodyContent in nested macros called without @ should be unset
> -
>
> Key: VELOCITY-940
> URL: https://issues.apache.org/jira/browse/VELOCITY-940
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 1.7.x, 2.3
>Reporter: Willow Nice
>Priority: Minor
>
> Hi! First ever maybe bug report (pls be gentle).
>
> {{#macro(test $label)Something $!label $!bodyContent#\{end}}}
> {{#@test('First')}}{{#test('Second')}}{{#end}}
>
> ends up a recurring mess because $bodyContent seems to be still defined when
> calling the inner macro without a block. I propose (perleeze) that it should
> always be unset when calling a macro without a block. It's fine if you always
> call with @ and supply an empty block, or unset it manually before the second
> call
> p.s.
> #@\{test} or #\{@test} doesn't work either
>
--
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-963) Incompatible API changes in 2.x
[ https://issues.apache.org/jira/browse/VELOCITY-963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17705046#comment-17705046 ] Michael Osipov commented on VELOCITY-963: - Unless there is a bug or documentation deficit, this issue should be closed since breaking changes are OK for a major version. > Incompatible API changes in 2.x > --- > > Key: VELOCITY-963 > URL: https://issues.apache.org/jira/browse/VELOCITY-963 > Project: Velocity > Issue Type: Bug > Components: Documentation >Affects Versions: 2.0, 2.1, 2.2, 2.3 >Reporter: Éamonn McManus >Priority: Minor > > I recently tried porting a large amount of Velocity client code from 1.7 to > 2.3 and discovered a number of incompatible API changes. Some of these were > probably unavoidable but at least one could be fixed to ease this kind of > migration. > * The three RuntimeInstance.parse methods from 1.7 were replaced by a single > RuntimeInstance.parse(Reader, Template) method. I found that I could work > around this by changing this: > SimpleNode node = runtimeInstance.parse(reader, resourceName); > to this: > Template template = new Template(); > template.setName(resourceName); > SimpleNode node = runtimeInstance.parse(reader, template); > But it would be convenient for people migrating if the old overloads were > restored. (This might not be the best way to parse a template, but it was > certainly quite widely used in the code I was porting.) > * VelocityContext(Map) becomes VelocityContext(Map). Some of > the code was passing a Map or a Map. That would > work if the argument type were Map, but I don't think that would > be correct since I believe the Map can be updated by #set directives. So > perhaps document this more explicitly. > * This abstract method in ResourceLoader > InputStream getResourceStream(String source) > becomes > Reader getResourceReader(String source, String encoding) > I'm not sure there would have been a good way to allow subclasses of > ResourceLoader to continue to work without change, and this change _is_ > documented in the [migration > guide|https://velocity.apache.org/engine/2.0/upgrading.html#behavior-api-changes] > so there's probably nothing further to do here. > * Nearly all the methods in StringUtils have been deleted, and that's not > mentioned in the migration guide. -- 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-963) Incompatible API changes in 2.x
[ https://issues.apache.org/jira/browse/VELOCITY-963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17705042#comment-17705042 ] Claude Brisson commented on VELOCITY-963: - IMO those are only points to document in the migration guide. Restoring an old method with a workaround inside is prone to side effects, now that the parser is supposed to know the template object. But thanks for the report! > Incompatible API changes in 2.x > --- > > Key: VELOCITY-963 > URL: https://issues.apache.org/jira/browse/VELOCITY-963 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.0, 2.1, 2.2, 2.3 >Reporter: Éamonn McManus >Priority: Minor > > I recently tried porting a large amount of Velocity client code from 1.7 to > 2.3 and discovered a number of incompatible API changes. Some of these were > probably unavoidable but at least one could be fixed to ease this kind of > migration. > * The three RuntimeInstance.parse methods from 1.7 were replaced by a single > RuntimeInstance.parse(Reader, Template) method. I found that I could work > around this by changing this: > SimpleNode node = runtimeInstance.parse(reader, resourceName); > to this: > Template template = new Template(); > template.setName(resourceName); > SimpleNode node = runtimeInstance.parse(reader, template); > But it would be convenient for people migrating if the old overloads were > restored. (This might not be the best way to parse a template, but it was > certainly quite widely used in the code I was porting.) > * VelocityContext(Map) becomes VelocityContext(Map). Some of > the code was passing a Map or a Map. That would > work if the argument type were Map, but I don't think that would > be correct since I believe the Map can be updated by #set directives. So > perhaps document this more explicitly. > * This abstract method in ResourceLoader > InputStream getResourceStream(String source) > becomes > Reader getResourceReader(String source, String encoding) > I'm not sure there would have been a good way to allow subclasses of > ResourceLoader to continue to work without change, and this change _is_ > documented in the [migration > guide|https://velocity.apache.org/engine/2.0/upgrading.html#behavior-api-changes] > so there's probably nothing further to do here. > * Nearly all the methods in StringUtils have been deleted, and that's not > mentioned in the migration guide. -- 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-963) Incompatible API changes in 2.x
[ https://issues.apache.org/jira/browse/VELOCITY-963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson updated VELOCITY-963: Component/s: Documentation (was: Engine) > Incompatible API changes in 2.x > --- > > Key: VELOCITY-963 > URL: https://issues.apache.org/jira/browse/VELOCITY-963 > Project: Velocity > Issue Type: Bug > Components: Documentation >Affects Versions: 2.0, 2.1, 2.2, 2.3 >Reporter: Éamonn McManus >Priority: Minor > > I recently tried porting a large amount of Velocity client code from 1.7 to > 2.3 and discovered a number of incompatible API changes. Some of these were > probably unavoidable but at least one could be fixed to ease this kind of > migration. > * The three RuntimeInstance.parse methods from 1.7 were replaced by a single > RuntimeInstance.parse(Reader, Template) method. I found that I could work > around this by changing this: > SimpleNode node = runtimeInstance.parse(reader, resourceName); > to this: > Template template = new Template(); > template.setName(resourceName); > SimpleNode node = runtimeInstance.parse(reader, template); > But it would be convenient for people migrating if the old overloads were > restored. (This might not be the best way to parse a template, but it was > certainly quite widely used in the code I was porting.) > * VelocityContext(Map) becomes VelocityContext(Map). Some of > the code was passing a Map or a Map. That would > work if the argument type were Map, but I don't think that would > be correct since I believe the Map can be updated by #set directives. So > perhaps document this more explicitly. > * This abstract method in ResourceLoader > InputStream getResourceStream(String source) > becomes > Reader getResourceReader(String source, String encoding) > I'm not sure there would have been a good way to allow subclasses of > ResourceLoader to continue to work without change, and this change _is_ > documented in the [migration > guide|https://velocity.apache.org/engine/2.0/upgrading.html#behavior-api-changes] > so there's probably nothing further to do here. > * Nearly all the methods in StringUtils have been deleted, and that's not > mentioned in the migration guide. -- 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] (VELTOOLS-197) xmlTool.find("./text()") (XPATH) not the same as xmlTool.getText () (METHOD) when & in text
[
https://issues.apache.org/jira/browse/VELTOOLS-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17704189#comment-17704189
]
Michael Osipov commented on VELTOOLS-197:
-
I absolutely agree on the trim. Violates POLA.
> xmlTool.find("./text()") (XPATH) not the same as xmlTool.getText () (METHOD)
> when & in text
> ---
>
> Key: VELTOOLS-197
> URL: https://issues.apache.org/jira/browse/VELTOOLS-197
> Project: Velocity Tools
> Issue Type: Bug
> Components: GenericTools
>Affects Versions: 3.1
>Reporter: steven van vlierberghe
>Priority: Major
>
> #foreach ($item2 in $xmlf1.find("/input/rep/x"))
> xpath: ${item2.find("./text()")} xml: $item2.getText()
> #end
> with $xmlf1 an XmlTool instance initialized on the following inputfile:
> {code:java}
>
>
> R&R
> R&B
>
>
> {code}
> using VeloctityTools-XmlTool 2.0 : find("./text()") returns same as
> getText() for an xmlTool instance (and complying with the expectation)
> {code:java}
> xpath: R&R xml: R&R
> xpath: R&B xml: R&B
> {code}
> However, using XmlTool 3.1, the xpath construct does not return the same as
> the getText,
> so the xpath does not comply with expectation
> {code:java}
> xpath: R&R xml: R&R
> xpath: R&B xml: R&B
> {code}
>
> PS:
> it can be solved in 3.1, by replacing $item2.find("./text()") by
> $item2.find("./text()").node().getNodeValue()
> BUT
> this really requires to adapt the script
> the actual problem is that I give support in our software to users for
> running their own Velocity scripts in our software.
> In the next version of our software, we upgraded Velocity + VelocityTools to
> 3.1
> and as a consequence, scripts of the users might break;
> meaning, this regression issue will impose our users to have to adapt their
> scripts that are used in production
> and for sure, they will not be happy having to do so
>
> PS2: also have the impression that plainly rendering $item2.find("./text()")
> as String also looses leading and trailing white space
>
> PS: the actual reason for upgrading VelocityTools (2.0 > 3.1) is that
> VeraCode flags the 2.0-related velocity libraries having vulnerabilities (and
> also dependent libraries like common- beanutils); these vulnerabilities have
> been solved in 3.1.
> Because there are (to us important) regression issues with upgrading the
> velocity stuff, we cannot upgrade and therefor remain stuck with flagged
> vulnerabilities in our software.
--
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] (VELTOOLS-197) xmlTool.find("./text()") (XPATH) not the same as xmlTool.getText () (METHOD) when & in text
[
https://issues.apache.org/jira/browse/VELTOOLS-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17704181#comment-17704181
]
steven van vlierberghe commented on VELTOOLS-197:
-
Also, in the new XmlTool.toString () method,
I guess it is a bad idea to call trim() on the returned string;
it would be better to just return as is.
> xmlTool.find("./text()") (XPATH) not the same as xmlTool.getText () (METHOD)
> when & in text
> ---
>
> Key: VELTOOLS-197
> URL: https://issues.apache.org/jira/browse/VELTOOLS-197
> Project: Velocity Tools
> Issue Type: Bug
> Components: GenericTools
>Affects Versions: 3.1
>Reporter: steven van vlierberghe
>Priority: Major
>
> #foreach ($item2 in $xmlf1.find("/input/rep/x"))
> xpath: ${item2.find("./text()")} xml: $item2.getText()
> #end
> with $xmlf1 an XmlTool instance initialized on the following inputfile:
> {code:java}
>
>
> R&R
> R&B
>
>
> {code}
> using VeloctityTools-XmlTool 2.0 : find("./text()") returns same as
> getText() for an xmlTool instance (and complying with the expectation)
> {code:java}
> xpath: R&R xml: R&R
> xpath: R&B xml: R&B
> {code}
> However, using XmlTool 3.1, the xpath construct does not return the same as
> the getText,
> so the xpath does not comply with expectation
> {code:java}
> xpath: R&R xml: R&R
> xpath: R&B xml: R&B
> {code}
>
> PS:
> it can be solved in 3.1, by replacing $item2.find("./text()") by
> $item2.find("./text()").node().getNodeValue()
> BUT
> this really requires to adapt the script
> the actual problem is that I give support in our software to users for
> running their own Velocity scripts in our software.
> In the next version of our software, we upgraded Velocity + VelocityTools to
> 3.1
> and as a consequence, scripts of the users might break;
> meaning, this regression issue will impose our users to have to adapt their
> scripts that are used in production
> and for sure, they will not be happy having to do so
>
> PS2: also have the impression that plainly rendering $item2.find("./text()")
> as String also looses leading and trailing white space
>
> PS: the actual reason for upgrading VelocityTools (2.0 > 3.1) is that
> VeraCode flags the 2.0-related velocity libraries having vulnerabilities (and
> also dependent libraries like common- beanutils); these vulnerabilities have
> been solved in 3.1.
> Because there are (to us important) regression issues with upgrading the
> velocity stuff, we cannot upgrade and therefor remain stuck with flagged
> vulnerabilities in our software.
--
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] (VELTOOLS-197) xmlTool.find("./text()") (XPATH) not the same as xmlTool.getText () (METHOD) when & in text
[
https://issues.apache.org/jira/browse/VELTOOLS-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17699514#comment-17699514
]
steven van vlierberghe commented on VELTOOLS-197:
-
An explanation for the difference between XMmlTools 2.0 and XmlTools 3.1
can be found in the XmlTools.toString () method (that gets called when XPath
returns a NodeSet, to be converted to a String, eventually):
the 2.0 implementation is based on dom4j.Node.asXML()
whereas the 3.1 implementation is based XmlUtils.nodeToString(org.w3c.dom.Node)
Adding a call to org.apache.commons.lang3.StringEscapeUtils.unescapeXml on the
returned result would solve my problem in 3.1...
> xmlTool.find("./text()") (XPATH) not the same as xmlTool.getText () (METHOD)
> when & in text
> ---
>
> Key: VELTOOLS-197
> URL: https://issues.apache.org/jira/browse/VELTOOLS-197
> Project: Velocity Tools
> Issue Type: Bug
> Components: GenericTools
>Affects Versions: 3.1
>Reporter: steven van vlierberghe
>Priority: Major
>
> #foreach ($item2 in $xmlf1.find("/input/rep/x"))
> xpath: ${item2.find("./text()")} xml: $item2.getText()
> #end
> with $xmlf1 an XmlTool instance initialized on the following inputfile:
> {code:java}
>
>
> R&R
> R&B
>
>
> {code}
> using VeloctityTools-XmlTool 2.0 : find("./text()") returns same as
> getText() for an xmlTool instance (and complying with the expectation)
> {code:java}
> xpath: R&R xml: R&R
> xpath: R&B xml: R&B
> {code}
> However, using XmlTool 3.1, the xpath construct does not return the same as
> the getText,
> so the xpath does not comply with expectation
> {code:java}
> xpath: R&R xml: R&R
> xpath: R&B xml: R&B
> {code}
>
> PS:
> it can be solved in 3.1, by replacing $item2.find("./text()") by
> $item2.find("./text()").node().getNodeValue()
> BUT
> this really requires to adapt the script
> the actual problem is that I give support in our software to users for
> running their own Velocity scripts in our software.
> In the next version of our software, we upgraded Velocity + VelocityTools to
> 3.1
> and as a consequence, scripts of the users might break;
> meaning, this regression issue will impose our users to have to adapt their
> scripts that are used in production
> and for sure, they will not be happy having to do so
>
> PS2: also have the impression that plainly rendering $item2.find("./text()")
> as String also looses leading and trailing white space
>
> PS: the actual reason for upgrading VelocityTools (2.0 > 3.1) is that
> VeraCode flags the 2.0-related velocity libraries having vulnerabilities (and
> also dependent libraries like common- beanutils); these vulnerabilities have
> been solved in 3.1.
> Because there are (to us important) regression issues with upgrading the
> velocity stuff, we cannot upgrade and therefor remain stuck with flagged
> vulnerabilities in our software.
--
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] (VELTOOLS-197) xmlTool.find("./text()") (XPATH) not the same as xmlTool.getText () (METHOD) when & in text
[
https://issues.apache.org/jira/browse/VELTOOLS-197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
steven van vlierberghe updated VELTOOLS-197:
Description:
#foreach ($item2 in $xmlf1.find("/input/rep/x"))
xpath: ${item2.find("./text()")} xml: $item2.getText()
#end
with $xmlf1 an XmlTool instance initialized on the following inputfile:
{code:java}
R&R
R&B
{code}
using VeloctityTools-XmlTool 2.0 : find("./text()") returns same as getText()
for an xmlTool instance (and complying with the expectation)
{code:java}
xpath: R&R xml: R&R
xpath: R&B xml: R&B
{code}
However, using XmlTool 3.1, the xpath construct does not return the same as the
getText,
so the xpath does not comply with expectation
{code:java}
xpath: R&R xml: R&R
xpath: R&B xml: R&B
{code}
PS:
it can be solved in 3.1, by replacing $item2.find("./text()") by
$item2.find("./text()").node().getNodeValue()
BUT
this really requires to adapt the script
the actual problem is that I give support in our software to users for running
their own Velocity scripts in our software.
In the next version of our software, we upgraded Velocity + VelocityTools to
3.1
and as a consequence, scripts of the users might break;
meaning, this regression issue will impose our users to have to adapt their
scripts that are used in production
and for sure, they will not be happy having to do so
PS2: also have the impression that plainly rendering $item2.find("./text()") as
String also looses leading and trailing white space
PS: the actual reason for upgrading VelocityTools (2.0 > 3.1) is that VeraCode
flags the 2.0-related velocity libraries having vulnerabilities (and also
dependent libraries like common- beanutils); these vulnerabilities have been
solved in 3.1.
Because there are (to us important) regression issues with upgrading the
velocity stuff, we cannot upgrade and therefor remain stuck with flagged
vulnerabilities in our software.
was:
#foreach ($item2 in $xmlf1.find("/input/rep/x"))
xpath: ${item2.find("./text()")} xml: $item2.getText()
#end
with $xmlf1 an XmlTool instance initialized on the following inputfile:
{code:java}
R&R
R&B
{code}
using VeloctityTools-XmlTool 2.0 : find("./text()") returns same as getText()
for an xmlTool instance (and complying with the expectation)
{code:java}
xpath: R&R xml: R&R
xpath: R&B xml: R&B
{code}
However, using XmlTool 3.1, the xpath construct does not return the same as the
getText,
so the xpath does not comply with expectation
{code:java}
xpath: R&R xml: R&R
xpath: R&B xml: R&B
{code}
PS:
it can be solved in 3.1, by replacing $item2.find("./text()") by
$item2.find("./text()").node().getNodeValue()
BUT
this really requires to adapt the script
the actual problem is that I give support in our software to users for running
their own Velocity scripts in our software.
In the next version of our software, we upgraded Velocity + VelocityTools to
3.1
and as a consequence, scripts of the users might break;
meaning, this regression issue will impose our users to have to adapt their
scripts that are used in production
and for sure, they will not be happy having to do so
PS2: also have the impression that plainly rendering $item2.find("./text()") as
String also looses leading and trailing white space
> xmlTool.find("./text()") (XPATH) not the same as xmlTool.getText () (METHOD)
> when & in text
> ---
>
> Key: VELTOOLS-197
> URL: https://issues.apache.org/jira/browse/VELTOOLS-197
> Project: Velocity Tools
> Issue Type: Bug
> Components: GenericTools
>Affects Versions: 3.1
>Reporter: steven van vlierberghe
>Priority: Major
>
> #foreach ($item2 in $xmlf1.find("/input/rep/x"))
> xpath: ${item2.find("./text()")} xml: $item2.getText()
> #end
> with $xmlf1 an XmlTool instance initialized on the following inputfile:
> {code:java}
>
>
> R&R
> R&B
>
>
> {code}
> using VeloctityTools-XmlTool 2.0 : find("./text()") returns same as
> getText() for an xmlTool instance (and complying with the expectation)
> {code:java}
> xpath: R&R xml: R&R
> xpath: R&B xml: R&B
> {code}
> However, using XmlTool 3.1, the xpath construct does not return the same as
> the getText,
> so the xpath does not comply with expectation
> {code:java}
> xpath: R&R xml: R&R
> xpath: R&B xml: R&B
> {code}
>
> PS
[jira] [Created] (VELOCITY-963) Incompatible API changes in 2.x
Éamonn McManus created VELOCITY-963: --- Summary: Incompatible API changes in 2.x Key: VELOCITY-963 URL: https://issues.apache.org/jira/browse/VELOCITY-963 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 2.3, 2.2, 2.1, 2.0 Reporter: Éamonn McManus I recently tried porting a large amount of Velocity client code from 1.7 to 2.3 and discovered a number of incompatible API changes. Some of these were probably unavoidable but at least one could be fixed to ease this kind of migration. * The three RuntimeInstance.parse methods from 1.7 were replaced by a single RuntimeInstance.parse(Reader, Template) method. I found that I could work around this by changing this: SimpleNode node = runtimeInstance.parse(reader, resourceName); to this: Template template = new Template(); template.setName(resourceName); SimpleNode node = runtimeInstance.parse(reader, template); But it would be convenient for people migrating if the old overloads were restored. (This might not be the best way to parse a template, but it was certainly quite widely used in the code I was porting.) * VelocityContext(Map) becomes VelocityContext(Map). Some of the code was passing a Map or a Map. That would work if the argument type were Map, but I don't think that would be correct since I believe the Map can be updated by #set directives. So perhaps document this more explicitly. * This abstract method in ResourceLoader InputStream getResourceStream(String source) becomes Reader getResourceReader(String source, String encoding) I'm not sure there would have been a good way to allow subclasses of ResourceLoader to continue to work without change, and this change _is_ documented in the [migration guide|https://velocity.apache.org/engine/2.0/upgrading.html#behavior-api-changes] so there's probably nothing further to do here. * Nearly all the methods in StringUtils have been deleted, and that's not mentioned in the migration guide. -- 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-962) Unclosed #[[ is no longer an error
[
https://issues.apache.org/jira/browse/VELOCITY-962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Éamonn McManus updated VELOCITY-962:
Description:
With Velocity 1.7, if you had {{#[[ without ]]#}} then you would get an
exception like this:
{noformat}
org.apache.velocity.runtime.parser.ParseException: Lexical error:
org.apache.velocity.runtime.parser.TokenMgrError: Lexical error at line 4,
column 5. Encountered: after : ""
at org.apache.velocity.runtime.parser.Parser.parse(Parser.java:136)
at
org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:1226)
at
org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:1181){noformat}
However, with 2.3 this is just silently accepted. I think it would be better to
continue to throw an exception, and better still if the exception message
indicated where the {{#[[}} started.
was:
With Velocity 1.7, if you had {{#[[}} without {{]]#}} then you would get an
exception like this:
{noformat}
org.apache.velocity.runtime.parser.ParseException: Lexical error:
org.apache.velocity.runtime.parser.TokenMgrError: Lexical error at line 4,
column 5. Encountered: after : ""
at org.apache.velocity.runtime.parser.Parser.parse(Parser.java:136)
at
org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:1226)
at
org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:1181){noformat}
However, with 2.3 this is just silently accepted. I think it would be better to
continue to throw an exception, and better still if the exception message
indicated where the {{#[[}} started.
> Unclosed #[[ is no longer an error
> --
>
> Key: VELOCITY-962
> URL: https://issues.apache.org/jira/browse/VELOCITY-962
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Éamonn McManus
>Priority: Minor
>
> With Velocity 1.7, if you had {{#[[ without ]]#}} then you would get an
> exception like this:
> {noformat}
> org.apache.velocity.runtime.parser.ParseException: Lexical error:
> org.apache.velocity.runtime.parser.TokenMgrError: Lexical error at line 4,
> column 5. Encountered: after : ""
> at org.apache.velocity.runtime.parser.Parser.parse(Parser.java:136)
> at
> org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:1226)
> at
> org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:1181){noformat}
> However, with 2.3 this is just silently accepted. I think it would be better
> to continue to throw an exception, and better still if the exception message
> indicated where the {{#[[}} started.
--
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-962) Unclosed #[[ is no longer an error
Éamonn McManus created VELOCITY-962:
---
Summary: Unclosed #[[ is no longer an error
Key: VELOCITY-962
URL: https://issues.apache.org/jira/browse/VELOCITY-962
Project: Velocity
Issue Type: Bug
Components: Engine
Affects Versions: 2.3
Reporter: Éamonn McManus
With Velocity 1.7, if you had {{#[[}} without {{]]#}} then you would get an
exception like this:
{noformat}
org.apache.velocity.runtime.parser.ParseException: Lexical error:
org.apache.velocity.runtime.parser.TokenMgrError: Lexical error at line 4,
column 5. Encountered: after : ""
at org.apache.velocity.runtime.parser.Parser.parse(Parser.java:136)
at
org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:1226)
at
org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:1181){noformat}
However, with 2.3 this is just silently accepted. I think it would be better to
continue to throw an exception, and better still if the exception message
indicated where the {{#[[}} started.
--
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-961) Parsing regression in Velocity 2.3
[
https://issues.apache.org/jira/browse/VELOCITY-961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Éamonn McManus updated VELOCITY-961:
Description:
The following template parses correctly with Velocity 1.7:
{noformat}
$child.typeName()#if($child.isRepeated())[]#end{noformat}
But with 2.3 it gets an exception:
{noformat}
org.apache.velocity.runtime.parser.TemplateParseException: Encountered "[" at
velocityParsingBug[line 1, column 42]
Was expecting one of:
"\u001c" ...
"\u001c" ...
"||" ...
"|" ...
"(" ...
")" ...
...
"]]#" ...
...
...
...
...
...
...
...
"{" ...
"}" ...
"" ...
"\\" ...
...
...
...
"{" ...
"\u001c" ...
...
... at
org.apache.velocity.runtime.parser.StandardParser.parse(StandardParser.java:198)
at
org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:1341){noformat}
I think the template is correct and should work with both versions.
I was able to work around the bug like this:
{noformat}
$set ($squares = '[]')
$child.typeName()#if($child.isRepeated())$squares#end{noformat}
was:
The following template parses correctly with Velocity 1.7:
{noformat}
$child.typeName()#if($child.isRepeated())[]#end{noformat}
But with 2.3 it gets an exception:
{noformat}
org.apache.velocity.runtime.parser.TemplateParseException: Encountered "[" at
velocityParsingBug[line 1, column 42]
Was expecting one of:
"\u001c" ...
"\u001c" ...
"||" ...
"|" ...
"(" ...
")" ...
...
"]]#" ...
...
...
...
...
...
...
...
"{" ...
"}" ...
"" ...
"\\" ...
...
...
...
"{" ...
"\u001c" ...
...
... at
org.apache.velocity.runtime.parser.StandardParser.parse(StandardParser.java:198)
at
org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:1341){noformat}
I think the template is correct and should work with both versions.
> Parsing regression in Velocity 2.3
> --
>
> Key: VELOCITY-961
> URL: https://issues.apache.org/jira/browse/VELOCITY-961
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Éamonn McManus
>Priority: Minor
>
> The following template parses correctly with Velocity 1.7:
> {noformat}
> $child.typeName()#if($child.isRepeated())[]#end{noformat}
> But with 2.3 it gets an exception:
> {noformat}
> org.apache.velocity.runtime.parser.TemplateParseException: Encountered "[" at
> velocityParsingBug[line 1, column 42]
> Was expecting one of:
> "\u001c" ...
> "\u001c" ...
> "||" ...
> "|" ...
> "(" ...
> ")" ...
> ...
> "]]#" ...
> ...
> ...
> ...
> ...
> ...
> ...
> ...
> "{" ...
> "}" ...
> "" ...
> "\\" ...
> ...
> ...
> ...
> "{" ...
> "\u001c" ...
> ...
> ... at
> org.apache.velocity.runtime.parser.StandardParser.parse(StandardParser.java:198)
> at
> org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:1341){noformat}
> I think the template is correct and should work with both versions.
> I was able to work around the bug like this:
> {noformat}
> $set ($squares = '[]')
> $child.typeName()#if($child.isRepeated())$squares#end{noformat}
--
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-961) Parsing regression in Velocity 2.3
Éamonn McManus created VELOCITY-961:
---
Summary: Parsing regression in Velocity 2.3
Key: VELOCITY-961
URL: https://issues.apache.org/jira/browse/VELOCITY-961
Project: Velocity
Issue Type: Bug
Components: Engine
Affects Versions: 2.3
Reporter: Éamonn McManus
The following template parses correctly with Velocity 1.7:
{noformat}
$child.typeName()#if($child.isRepeated())[]#end{noformat}
But with 2.3 it gets an exception:
{noformat}
org.apache.velocity.runtime.parser.TemplateParseException: Encountered "[" at
velocityParsingBug[line 1, column 42]
Was expecting one of:
"\u001c" ...
"\u001c" ...
"||" ...
"|" ...
"(" ...
")" ...
...
"]]#" ...
...
...
...
...
...
...
...
"{" ...
"}" ...
"" ...
"\\" ...
...
...
...
"{" ...
"\u001c" ...
...
... at
org.apache.velocity.runtime.parser.StandardParser.parse(StandardParser.java:198)
at
org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:1341){noformat}
I think the template is correct and should work with both versions.
--
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] (VELTOOLS-200) Current Velocity Tools View use deprecated Velocity properties
[
https://issues.apache.org/jira/browse/VELTOOLS-200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated VELTOOLS-200:
Summary: Current Velocity Tools View use deprecated Velocity properties
(was: current Velocity Tools use deprecated Velocity properties )
> Current Velocity Tools View use deprecated Velocity properties
> ---
>
> Key: VELTOOLS-200
> URL: https://issues.apache.org/jira/browse/VELTOOLS-200
> Project: Velocity Tools
> Issue Type: Bug
> Components: VelocityView
>Affects Versions: 3.1
>Reporter: Gernot Hueller
>Priority: Minor
>
> when using current Velocity with current Velocity Tools View , I get the
> following error messages in the log:
> {{org.apache.velocity.deprecation - configuration key 'resource.loader' has
> been deprecated in favor of 'resource.loaders'}}
> {{org.apache.velocity.deprecation - configuration key
> 'webapp.resource.loader.class' has been deprecated in favor of
> 'resource.loader.webapp.class'}}
> {{org.apache.velocity.deprecation - configuration key
> 'string.resource.loader.class' has been deprecated in favor of
> 'resource.loader.string.class'}}
> {{org.apache.velocity.deprecation - configuration key
> 'runtime.introspector.uberspect' has been deprecated in favor of
> 'introspector.uberspect.class'}}
>
> OK so maybe the old property names are used to be compatible to old Velocity
> Engine versions, but the default is that we use current versions - so a
> "compatibility mode" should be made smarter than just continuing to use
> deprecated properties.
> my gradle includes:
> {{earlib group: 'org.apache.velocity', name: 'velocity-engine-core', version:
> '2.3'}}
> {{earlib group: 'org.apache.velocity.tools', name: 'velocity-tools-view',
> version: '3.1'}}
>
> This has also been mentioned in a recent stackoverflow thread
> https://stackoverflow.com/questions/73026164/velocity-warnings-about-deprecated-keys-that-i-dont-even-use
--
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] (VELTOOLS-200) current Velocity Tools use deprecated Velocity properties
Gernot Hueller created VELTOOLS-200:
---
Summary: current Velocity Tools use deprecated Velocity properties
Key: VELTOOLS-200
URL: https://issues.apache.org/jira/browse/VELTOOLS-200
Project: Velocity Tools
Issue Type: Bug
Components: VelocityView
Affects Versions: 3.1
Reporter: Gernot Hueller
when using current Velocity with current Velocity Tools View , I get the
following error messages in the log:
{{org.apache.velocity.deprecation - configuration key 'resource.loader' has
been deprecated in favor of 'resource.loaders'}}
{{org.apache.velocity.deprecation - configuration key
'webapp.resource.loader.class' has been deprecated in favor of
'resource.loader.webapp.class'}}
{{org.apache.velocity.deprecation - configuration key
'string.resource.loader.class' has been deprecated in favor of
'resource.loader.string.class'}}
{{org.apache.velocity.deprecation - configuration key
'runtime.introspector.uberspect' has been deprecated in favor of
'introspector.uberspect.class'}}
OK so maybe the old property names are used to be compatible to old Velocity
Engine versions, but the default is that we use current versions - so a
"compatibility mode" should be made smarter than just continuing to use
deprecated properties.
my gradle includes:
{{earlib group: 'org.apache.velocity', name: 'velocity-engine-core', version:
'2.3'}}
{{earlib group: 'org.apache.velocity.tools', name: 'velocity-tools-view',
version: '3.1'}}
This has also been mentioned in a recent stackoverflow thread
https://stackoverflow.com/questions/73026164/velocity-warnings-about-deprecated-keys-that-i-dont-even-use
--
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] (VELTOOLS-199) org.apache.velocity.tools.generic.ClassTool methods does not include inherited methods
Alex O'Ree created VELTOOLS-199: --- Summary: org.apache.velocity.tools.generic.ClassTool methods does not include inherited methods Key: VELTOOLS-199 URL: https://issues.apache.org/jira/browse/VELTOOLS-199 Project: Velocity Tools Issue Type: Bug Reporter: Alex O'Ree using tools 3.1 and using the class tool against a class that implements an interface and extends an abstract class. The class tools "methods" operation only returns methods directly implemented by the class and does not return any methods implemented by the abstract nor the interface. I'm not sure if this was on purpose, but it's pretty easy to get with reflection -- 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] (VELTOOLS-184) EscapeTool: add a json method, or a javascript method with a second parameter
[ https://issues.apache.org/jira/browse/VELTOOLS-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17636051#comment-17636051 ] Christopher Schultz commented on VELTOOLS-184: -- I stand corrected. > EscapeTool: add a json method, or a javascript method with a second parameter > - > > Key: VELTOOLS-184 > URL: https://issues.apache.org/jira/browse/VELTOOLS-184 > Project: Velocity Tools > Issue Type: Improvement > Components: GenericTools >Affects Versions: 2.x > Environment: any >Reporter: Maurice Perry >Priority: Minor > Labels: EscapeTool, escape, javascript, json > > The string returned by EscapeTool.javascript() method is not alway compliant > with the JSON syntax. For instance, when the input string contains an > apostrophe ', a backslash is inserted before it because there is no way for > the method to know if the string is enclosed with single or double quotes. > This is not compliant with the JSON syntax, and some JSON parsers will reject > the string. > There may be other differences between javascript and JSON strings, but this > is the one I encountered, and I had to use a workaround. > This issue can be solved either with a JSON method, or with a second > javascript method with a second parameter indicating the type of quote used. -- 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] (VELTOOLS-184) EscapeTool: add a json method, or a javascript method with a second parameter
[
https://issues.apache.org/jira/browse/VELTOOLS-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17636048#comment-17636048
]
Maurice Perry edited comment on VELTOOLS-184 at 11/18/22 9:56 PM:
--
You misread the RFC: any character can be escaped using a UNICODE hexadecimal
number, but only some can be directly escaped by preceding them with a
backslash:
{{{}string = quotation-mark *char quotation-mark{}}}{{{}char = unescaped /{}}}
{{escape (}}
{{%x22 / ; " quotation mark U+0022}}
{{%x5C / ; \ reverse solidus U+005C}}
{{%x2F / ; / solidus U+002F}}
{{%x62 / ; b backspace U+0008}}
{{%x66 / ; f form feed U+000C}}
{{%x6E / ; n line feed U+000A}}
{{%x72 / ; r carriage return U+000D}}
{{%x74 / ; t tab U+0009}}
{{{}%x75 4HEXDIG ) ; u U+{}}}{{{}escape = %x5C ;
\{}}}{{{}quotation-mark = %x22 ; "{}}}{{{}unescaped = %x20-21 / %x23-5B /
%x5D-10{}}}
The single quote is NOT one of them.
was (Author: robbyn):
You misread the RFC: any character can be escaped using a UNICODE hexadecimal
number, but only some can be directly escaped by preceding them with a
backslash:
string = quotation-mark *char quotation-mark
char = unescaped /
escape (
%x22 / ; "quotation mark U+0022
%x5C / ; \reverse solidus U+005C
%x2F / ; /solidus U+002F
%x62 / ; bbackspace U+0008
%x66 / ; fform feed U+000C
%x6E / ; nline feed U+000A
%x72 / ; rcarriage return U+000D
%x74 / ; ttab U+0009
%x75 4HEXDIG ) ; uU+
escape = %x5C ; \
quotation-mark = %x22 ; "
unescaped = %x20-21 / %x23-5B / %x5D-10
> EscapeTool: add a json method, or a javascript method with a second parameter
> -
>
> Key: VELTOOLS-184
> URL: https://issues.apache.org/jira/browse/VELTOOLS-184
> Project: Velocity Tools
> Issue Type: Improvement
> Components: GenericTools
>Affects Versions: 2.x
> Environment: any
>Reporter: Maurice Perry
>Priority: Minor
> Labels: EscapeTool, escape, javascript, json
>
> The string returned by EscapeTool.javascript() method is not alway compliant
> with the JSON syntax. For instance, when the input string contains an
> apostrophe ', a backslash is inserted before it because there is no way for
> the method to know if the string is enclosed with single or double quotes.
> This is not compliant with the JSON syntax, and some JSON parsers will reject
> the string.
> There may be other differences between javascript and JSON strings, but this
> is the one I encountered, and I had to use a workaround.
> This issue can be solved either with a JSON method, or with a second
> javascript method with a second parameter indicating the type of quote used.
--
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] (VELTOOLS-184) EscapeTool: add a json method, or a javascript method with a second parameter
[ https://issues.apache.org/jira/browse/VELTOOLS-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17636048#comment-17636048 ] Maurice Perry commented on VELTOOLS-184: You misread the RFC: any character can be escaped using a UNICODE hexadecimal number, but only some can be directly escaped by preceding them with a backslash: string = quotation-mark *char quotation-mark char = unescaped / escape ( %x22 / ; "quotation mark U+0022 %x5C / ; \reverse solidus U+005C %x2F / ; /solidus U+002F %x62 / ; bbackspace U+0008 %x66 / ; fform feed U+000C %x6E / ; nline feed U+000A %x72 / ; rcarriage return U+000D %x74 / ; ttab U+0009 %x75 4HEXDIG ) ; uU+ escape = %x5C ; \ quotation-mark = %x22 ; " unescaped = %x20-21 / %x23-5B / %x5D-10 > EscapeTool: add a json method, or a javascript method with a second parameter > - > > Key: VELTOOLS-184 > URL: https://issues.apache.org/jira/browse/VELTOOLS-184 > Project: Velocity Tools > Issue Type: Improvement > Components: GenericTools >Affects Versions: 2.x > Environment: any >Reporter: Maurice Perry >Priority: Minor > Labels: EscapeTool, escape, javascript, json > > The string returned by EscapeTool.javascript() method is not alway compliant > with the JSON syntax. For instance, when the input string contains an > apostrophe ', a backslash is inserted before it because there is no way for > the method to know if the string is enclosed with single or double quotes. > This is not compliant with the JSON syntax, and some JSON parsers will reject > the string. > There may be other differences between javascript and JSON strings, but this > is the one I encountered, and I had to use a workaround. > This issue can be solved either with a JSON method, or with a second > javascript method with a second parameter indicating the type of quote used. -- 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] (VELTOOLS-184) EscapeTool: add a json method, or a javascript method with a second parameter
[ https://issues.apache.org/jira/browse/VELTOOLS-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17636011#comment-17636011 ] Claude Brisson commented on VELTOOLS-184: - There may be broken Json parsers in the wild, but that's not a reason for us to escape things that don't need to be. > EscapeTool: add a json method, or a javascript method with a second parameter > - > > Key: VELTOOLS-184 > URL: https://issues.apache.org/jira/browse/VELTOOLS-184 > Project: Velocity Tools > Issue Type: Improvement > Components: GenericTools >Affects Versions: 2.x > Environment: any >Reporter: Maurice Perry >Priority: Minor > Labels: EscapeTool, escape, javascript, json > > The string returned by EscapeTool.javascript() method is not alway compliant > with the JSON syntax. For instance, when the input string contains an > apostrophe ', a backslash is inserted before it because there is no way for > the method to know if the string is enclosed with single or double quotes. > This is not compliant with the JSON syntax, and some JSON parsers will reject > the string. > There may be other differences between javascript and JSON strings, but this > is the one I encountered, and I had to use a workaround. > This issue can be solved either with a JSON method, or with a second > javascript method with a second parameter indicating the type of quote used. -- 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] (VELTOOLS-184) EscapeTool: add a json method, or a javascript method with a second parameter
[
https://issues.apache.org/jira/browse/VELTOOLS-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17635999#comment-17635999
]
Christopher Schultz edited comment on VELTOOLS-184 at 11/18/22 7:12 PM:
I'm sorry, but whatever JSON parser you are working with is patently broken.
Quoting [RFC 4627, section
2.5|https://www.ietf.org/rfc/rfc4627.html#section-2.5]:
{quote}Any character may be escaped.
{quote}
So, breaking when ' is (perhaps unexpectedly) escaped means that {_}the library
is broken{_}.
was (Author: ch...@christopherschultz.net):
I'm sorry, but whatever JSON parser you are working with is patently broken.
Quoting [RFC 4627, section
2.5|[http://example.com|https://www.ietf.org/rfc/rfc4627.html#section-2.5]]:
{quote}Any character may be escaped.
{quote}
So, breaking when ' is (perhaps unexpectedly) escaped means that {_}the library
is broken{_}.
> EscapeTool: add a json method, or a javascript method with a second parameter
> -
>
> Key: VELTOOLS-184
> URL: https://issues.apache.org/jira/browse/VELTOOLS-184
> Project: Velocity Tools
> Issue Type: Improvement
> Components: GenericTools
>Affects Versions: 2.x
> Environment: any
>Reporter: Maurice Perry
>Priority: Minor
> Labels: EscapeTool, escape, javascript, json
>
> The string returned by EscapeTool.javascript() method is not alway compliant
> with the JSON syntax. For instance, when the input string contains an
> apostrophe ', a backslash is inserted before it because there is no way for
> the method to know if the string is enclosed with single or double quotes.
> This is not compliant with the JSON syntax, and some JSON parsers will reject
> the string.
> There may be other differences between javascript and JSON strings, but this
> is the one I encountered, and I had to use a workaround.
> This issue can be solved either with a JSON method, or with a second
> javascript method with a second parameter indicating the type of quote used.
--
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] (VELTOOLS-184) EscapeTool: add a json method, or a javascript method with a second parameter
[
https://issues.apache.org/jira/browse/VELTOOLS-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17635999#comment-17635999
]
Christopher Schultz commented on VELTOOLS-184:
--
I'm sorry, but whatever JSON parser you are working with is patently broken.
Quoting [RFC 4627, section
2.5|[http://example.com|https://www.ietf.org/rfc/rfc4627.html#section-2.5]]:
{quote}Any character may be escaped.
{quote}
So, breaking when ' is (perhaps unexpectedly) escaped means that {_}the library
is broken{_}.
> EscapeTool: add a json method, or a javascript method with a second parameter
> -
>
> Key: VELTOOLS-184
> URL: https://issues.apache.org/jira/browse/VELTOOLS-184
> Project: Velocity Tools
> Issue Type: Improvement
> Components: GenericTools
>Affects Versions: 2.x
> Environment: any
>Reporter: Maurice Perry
>Priority: Minor
> Labels: EscapeTool, escape, javascript, json
>
> The string returned by EscapeTool.javascript() method is not alway compliant
> with the JSON syntax. For instance, when the input string contains an
> apostrophe ', a backslash is inserted before it because there is no way for
> the method to know if the string is enclosed with single or double quotes.
> This is not compliant with the JSON syntax, and some JSON parsers will reject
> the string.
> There may be other differences between javascript and JSON strings, but this
> is the one I encountered, and I had to use a workaround.
> This issue can be solved either with a JSON method, or with a second
> javascript method with a second parameter indicating the type of quote used.
--
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-960) Documentation inconsistency for use of hypens on identifiers
[
https://issues.apache.org/jira/browse/VELOCITY-960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17631233#comment-17631233
]
Michael Osipov commented on VELOCITY-960:
-
Merci, Claude.
> Documentation inconsistency for use of hypens on identifiers
> -
>
> Key: VELOCITY-960
> URL: https://issues.apache.org/jira/browse/VELOCITY-960
> Project: Velocity
> Issue Type: Bug
>Reporter: Cesar Alvernaz
>Assignee: Claude Brisson
>Priority: Major
> Labels: doc
> Fix For: 2.3
>
>
> Regarding the use of hypens on identifiers, the documentation doesn't look
> consistent. Which one is recommended?
> [Here|https://velocity.apache.org/engine/2.3/configuration.html] states the
> following:
> *{{parser.allow_hyphen_in_identifiers = false}}*
> {quote}This is a backward compatibility option, false by default, which
> allows the '{*}{{-}}{*}' character inside variable identifiers (available
> since 2.1). If enabled, be warned that you will have to surround the
> mathematical minus sign with spaces for it to be correctly interpreted.
> {quote}
>
> But [here|https://velocity.apache.org/engine/2.3/vtl-reference.html], the
> configuration is different:
> {quote}{{If the *parser.allows.dash.identifiers*}} configuration value is set
> to true, then the *-* dash is also allowed in identifiers (and must be
> surrounded by spaces to be interpreted as an arithmetic minus operator).}}
> {quote}
--
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] [Resolved] (VELOCITY-960) Documentation inconsistency for use of hypens on identifiers
[
https://issues.apache.org/jira/browse/VELOCITY-960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson resolved VELOCITY-960.
-
Fix Version/s: 2.3
Assignee: Claude Brisson
Resolution: Fixed
The fix has been commited to the site sources and to the production branch.
It's not yet visible but should be soon (or it's a problem and we'll contact
infra).
No more mention of any "dash".
> Documentation inconsistency for use of hypens on identifiers
> -
>
> Key: VELOCITY-960
> URL: https://issues.apache.org/jira/browse/VELOCITY-960
> Project: Velocity
> Issue Type: Bug
>Reporter: Cesar Alvernaz
>Assignee: Claude Brisson
>Priority: Major
> Labels: doc
> Fix For: 2.3
>
>
> Regarding the use of hypens on identifiers, the documentation doesn't look
> consistent. Which one is recommended?
> [Here|https://velocity.apache.org/engine/2.3/configuration.html] states the
> following:
> *{{parser.allow_hyphen_in_identifiers = false}}*
> {quote}This is a backward compatibility option, false by default, which
> allows the '{*}{{-}}{*}' character inside variable identifiers (available
> since 2.1). If enabled, be warned that you will have to surround the
> mathematical minus sign with spaces for it to be correctly interpreted.
> {quote}
>
> But [here|https://velocity.apache.org/engine/2.3/vtl-reference.html], the
> configuration is different:
> {quote}{{If the *parser.allows.dash.identifiers*}} configuration value is set
> to true, then the *-* dash is also allowed in identifiers (and must be
> surrounded by spaces to be interpreted as an arithmetic minus operator).}}
> {quote}
--
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-960) Documentation inconsistency for use of hypens on identifiers
[
https://issues.apache.org/jira/browse/VELOCITY-960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17631027#comment-17631027
]
Michael Osipov edited comment on VELOCITY-960 at 11/9/22 12:01 PM:
---
The "parser.allows.dash.identifiers" mention is a reference to a long
disappeared name for this property.
The property name is "parser.allow_hyphen_in_identifiers", and it's a hyphen,
we're all good.
[~calvernaz] Thanks for catching this documentation glitch!
was (Author: claude):
The "parser.allows.dash.identifiers" mention is a reference to a long
disappeared name for this property.
The property name is "parser.allow_hyphen_in_identifiers", and it's a hyphen,
we're all good.
[~calvernaz] Thanks for catching this documentation glinche!
> Documentation inconsistency for use of hypens on identifiers
> -
>
> Key: VELOCITY-960
> URL: https://issues.apache.org/jira/browse/VELOCITY-960
> Project: Velocity
> Issue Type: Bug
>Reporter: Cesar Alvernaz
>Priority: Major
> Labels: doc
>
> Regarding the use of hypens on identifiers, the documentation doesn't look
> consistent. Which one is recommended?
> [Here|https://velocity.apache.org/engine/2.3/configuration.html] states the
> following:
> *{{parser.allow_hyphen_in_identifiers = false}}*
> {quote}This is a backward compatibility option, false by default, which
> allows the '{*}{{-}}{*}' character inside variable identifiers (available
> since 2.1). If enabled, be warned that you will have to surround the
> mathematical minus sign with spaces for it to be correctly interpreted.
> {quote}
>
> But [here|https://velocity.apache.org/engine/2.3/vtl-reference.html], the
> configuration is different:
> {quote}{{If the *parser.allows.dash.identifiers*}} configuration value is set
> to true, then the *-* dash is also allowed in identifiers (and must be
> surrounded by spaces to be interpreted as an arithmetic minus operator).}}
> {quote}
--
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-960) Documentation inconsistency for use of hypens on identifiers
[
https://issues.apache.org/jira/browse/VELOCITY-960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17631027#comment-17631027
]
Claude Brisson commented on VELOCITY-960:
-
The "parser.allows.dash.identifiers" mention is a reference to a long
disappeared name for this property.
The property name is "parser.allow_hyphen_in_identifiers", and it's a hyphen,
we're all good.
[~calvernaz] Thanks for catching this documentation glinche!
> Documentation inconsistency for use of hypens on identifiers
> -
>
> Key: VELOCITY-960
> URL: https://issues.apache.org/jira/browse/VELOCITY-960
> Project: Velocity
> Issue Type: Bug
>Reporter: Cesar Alvernaz
>Priority: Major
> Labels: doc
>
> Regarding the use of hypens on identifiers, the documentation doesn't look
> consistent. Which one is recommended?
> [Here|https://velocity.apache.org/engine/2.3/configuration.html] states the
> following:
> *{{parser.allow_hyphen_in_identifiers = false}}*
> {quote}This is a backward compatibility option, false by default, which
> allows the '{*}{{-}}{*}' character inside variable identifiers (available
> since 2.1). If enabled, be warned that you will have to surround the
> mathematical minus sign with spaces for it to be correctly interpreted.
> {quote}
>
> But [here|https://velocity.apache.org/engine/2.3/vtl-reference.html], the
> configuration is different:
> {quote}{{If the *parser.allows.dash.identifiers*}} configuration value is set
> to true, then the *-* dash is also allowed in identifiers (and must be
> surrounded by spaces to be interpreted as an arithmetic minus operator).}}
> {quote}
--
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-960) Documentation inconsistency for use of hypens on identifiers
[
https://issues.apache.org/jira/browse/VELOCITY-960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17630858#comment-17630858
]
Michael Osipov commented on VELOCITY-960:
-
I need to create a followup ticket. A dash is *not* a hyphen. That property
needs to be changed in the future.
> Documentation inconsistency for use of hypens on identifiers
> -
>
> Key: VELOCITY-960
> URL: https://issues.apache.org/jira/browse/VELOCITY-960
> Project: Velocity
> Issue Type: Bug
>Reporter: Cesar Alvernaz
>Priority: Major
> Labels: doc
>
> Regarding the use of hypens on identifiers, the documentation doesn't look
> consistent. Which one is recommended?
> [Here|https://velocity.apache.org/engine/2.3/configuration.html] states the
> following:
> *{{parser.allow_hyphen_in_identifiers = false}}*
> {quote}This is a backward compatibility option, false by default, which
> allows the '{*}{{-}}{*}' character inside variable identifiers (available
> since 2.1). If enabled, be warned that you will have to surround the
> mathematical minus sign with spaces for it to be correctly interpreted.
> {quote}
>
> But [here|https://velocity.apache.org/engine/2.3/vtl-reference.html], the
> configuration is different:
> {quote}{{If the *parser.allows.dash.identifiers*}} configuration value is set
> to true, then the *-* dash is also allowed in identifiers (and must be
> surrounded by spaces to be interpreted as an arithmetic minus operator).}}
> {quote}
--
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-960) Documentation inconsistency for use of hypens on identifiers
[
https://issues.apache.org/jira/browse/VELOCITY-960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated VELOCITY-960:
Summary: Documentation inconsistency for use of hypens on identifiers
(was: Documentation inconsistency for use of dashes on identifiers )
> Documentation inconsistency for use of hypens on identifiers
> -
>
> Key: VELOCITY-960
> URL: https://issues.apache.org/jira/browse/VELOCITY-960
> Project: Velocity
> Issue Type: Bug
>Reporter: Cesar Alvernaz
>Priority: Major
> Labels: doc
>
> Regarding the use of dashes on identifiers, the documentation doesn't look
> consistent. Which one is recommended?
> [Here|https://velocity.apache.org/engine/2.3/configuration.html] states the
> following:
> *{{parser.allow_hyphen_in_identifiers = false}}*
> {quote}This is a backward compatibility option, false by default, which
> allows the '{*}{{-}}{*}' character inside variable identifiers (available
> since 2.1). If enabled, be warned that you will have to surround the
> mathematical minus sign with spaces for it to be correctly interpreted.
> {quote}
>
> But [here|https://velocity.apache.org/engine/2.3/vtl-reference.html], the
> configuration is different:
> {quote}{{If the *parser.allows.dash.identifiers*}} configuration value is set
> to true, then the *-* dash is also allowed in identifiers (and must be
> surrounded by spaces to be interpreted as an arithmetic minus operator).}}
> {quote}
--
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-960) Documentation inconsistency for use of hypens on identifiers
[
https://issues.apache.org/jira/browse/VELOCITY-960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated VELOCITY-960:
Description:
Regarding the use of hypens on identifiers, the documentation doesn't look
consistent. Which one is recommended?
[Here|https://velocity.apache.org/engine/2.3/configuration.html] states the
following:
*{{parser.allow_hyphen_in_identifiers = false}}*
{quote}This is a backward compatibility option, false by default, which allows
the '{*}{{-}}{*}' character inside variable identifiers (available since 2.1).
If enabled, be warned that you will have to surround the mathematical minus
sign with spaces for it to be correctly interpreted.
{quote}
But [here|https://velocity.apache.org/engine/2.3/vtl-reference.html], the
configuration is different:
{quote}{{If the *parser.allows.dash.identifiers*}} configuration value is set
to true, then the *-* dash is also allowed in identifiers (and must be
surrounded by spaces to be interpreted as an arithmetic minus operator).}}
{quote}
was:
Regarding the use of dashes on identifiers, the documentation doesn't look
consistent. Which one is recommended?
[Here|https://velocity.apache.org/engine/2.3/configuration.html] states the
following:
*{{parser.allow_hyphen_in_identifiers = false}}*
{quote}This is a backward compatibility option, false by default, which allows
the '{*}{{-}}{*}' character inside variable identifiers (available since 2.1).
If enabled, be warned that you will have to surround the mathematical minus
sign with spaces for it to be correctly interpreted.
{quote}
But [here|https://velocity.apache.org/engine/2.3/vtl-reference.html], the
configuration is different:
{quote}{{If the *parser.allows.dash.identifiers*}} configuration value is set
to true, then the *-* dash is also allowed in identifiers (and must be
surrounded by spaces to be interpreted as an arithmetic minus operator).}}
{quote}
> Documentation inconsistency for use of hypens on identifiers
> -
>
> Key: VELOCITY-960
> URL: https://issues.apache.org/jira/browse/VELOCITY-960
> Project: Velocity
> Issue Type: Bug
>Reporter: Cesar Alvernaz
>Priority: Major
> Labels: doc
>
> Regarding the use of hypens on identifiers, the documentation doesn't look
> consistent. Which one is recommended?
> [Here|https://velocity.apache.org/engine/2.3/configuration.html] states the
> following:
> *{{parser.allow_hyphen_in_identifiers = false}}*
> {quote}This is a backward compatibility option, false by default, which
> allows the '{*}{{-}}{*}' character inside variable identifiers (available
> since 2.1). If enabled, be warned that you will have to surround the
> mathematical minus sign with spaces for it to be correctly interpreted.
> {quote}
>
> But [here|https://velocity.apache.org/engine/2.3/vtl-reference.html], the
> configuration is different:
> {quote}{{If the *parser.allows.dash.identifiers*}} configuration value is set
> to true, then the *-* dash is also allowed in identifiers (and must be
> surrounded by spaces to be interpreted as an arithmetic minus operator).}}
> {quote}
--
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-960) Documentation inconsistency for use of dashes on identifiers
[
https://issues.apache.org/jira/browse/VELOCITY-960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cesar Alvernaz updated VELOCITY-960:
Description:
Regarding the use of dashes on identifiers, the documentation doesn't look
consistent. Which one is recommended?
[Here|https://velocity.apache.org/engine/2.3/configuration.html] states the
following:
*{{parser.allow_hyphen_in_identifiers = false}}*
{quote}This is a backward compatibility option, false by default, which allows
the '{*}{{-}}{*}' character inside variable identifiers (available since 2.1).
If enabled, be warned that you will have to surround the mathematical minus
sign with spaces for it to be correctly interpreted.
{quote}
But [here|https://velocity.apache.org/engine/2.3/vtl-reference.html], the
configuration is different:
{quote}{{If the *parser.allows.dash.identifiers*}} configuration value is set
to true, then the *-* dash is also allowed in identifiers (and must be
surrounded by spaces to be interpreted as an arithmetic minus operator).}}
{quote}
was:
Regarding the use of dashes on identifiers, the documentation doesn't look
consistent. Which one is recommended?
[Here|[https://velocity.apache.org/engine/2.3/configuration.html]] states the
following:
*{{parser.allow_hyphen_in_identifiers = false}}*
{quote}This is a backward compatibility option, false by default, which allows
the '{*}{{-}}{*}' character inside variable identifiers (available since 2.1).
If enabled, be warned that you will have to surround the mathematical minus
sign with spaces for it to be correctly interpreted.
{quote}
But [here|[https://velocity.apache.org/engine/2.3/vtl-reference.html]], the
configuration is different:
{quote}{{If the {{*parser.allows.dash.identifiers*}} configuration value is set
to true, then the *-* dash is also allowed in identifiers (and must be
surrounded by spaces to be interpreted as an arithmetic minus operator).}}
{quote}
Labels: doc (was: )
> Documentation inconsistency for use of dashes on identifiers
> -
>
> Key: VELOCITY-960
> URL: https://issues.apache.org/jira/browse/VELOCITY-960
> Project: Velocity
> Issue Type: Bug
>Reporter: Cesar Alvernaz
>Priority: Major
> Labels: doc
>
> Regarding the use of dashes on identifiers, the documentation doesn't look
> consistent. Which one is recommended?
> [Here|https://velocity.apache.org/engine/2.3/configuration.html] states the
> following:
> *{{parser.allow_hyphen_in_identifiers = false}}*
> {quote}This is a backward compatibility option, false by default, which
> allows the '{*}{{-}}{*}' character inside variable identifiers (available
> since 2.1). If enabled, be warned that you will have to surround the
> mathematical minus sign with spaces for it to be correctly interpreted.
> {quote}
>
> But [here|https://velocity.apache.org/engine/2.3/vtl-reference.html], the
> configuration is different:
> {quote}{{If the *parser.allows.dash.identifiers*}} configuration value is set
> to true, then the *-* dash is also allowed in identifiers (and must be
> surrounded by spaces to be interpreted as an arithmetic minus operator).}}
> {quote}
--
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-960) Documentation inconsistency for use of dashes on identifiers
Cesar Alvernaz created VELOCITY-960:
---
Summary: Documentation inconsistency for use of dashes on
identifiers
Key: VELOCITY-960
URL: https://issues.apache.org/jira/browse/VELOCITY-960
Project: Velocity
Issue Type: Bug
Reporter: Cesar Alvernaz
Regarding the use of dashes on identifiers, the documentation doesn't look
consistent. Which one is recommended?
[Here|[https://velocity.apache.org/engine/2.3/configuration.html]] states the
following:
*{{parser.allow_hyphen_in_identifiers = false}}*
{quote}This is a backward compatibility option, false by default, which allows
the '{*}{{-}}{*}' character inside variable identifiers (available since 2.1).
If enabled, be warned that you will have to surround the mathematical minus
sign with spaces for it to be correctly interpreted.
{quote}
But [here|[https://velocity.apache.org/engine/2.3/vtl-reference.html]], the
configuration is different:
{quote}{{If the {{*parser.allows.dash.identifiers*}} configuration value is set
to true, then the *-* dash is also allowed in identifiers (and must be
surrounded by spaces to be interpreted as an arithmetic minus operator).}}
{quote}
--
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] (VELTOOLS-198) org.apache.velocity.tools.ConversionUtils#getNumberFormat(java.lang.String, java.util.Locale) is not thread safe for custom formats
[
https://issues.apache.org/jira/browse/VELTOOLS-198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17630583#comment-17630583
]
Michael Osipov commented on VELTOOLS-198:
-
So basically we are talking about
{{org.apache.velocity.tools.generic.NumberTool.getNumberFormat(String,
Locale)]] and {{org.apache.velocity.tools.generic.NumberTool.format()}}? I
agree that the NFs require external synchronization.
> org.apache.velocity.tools.ConversionUtils#getNumberFormat(java.lang.String,
> java.util.Locale) is not thread safe for custom formats
> ---
>
> Key: VELTOOLS-198
> URL: https://issues.apache.org/jira/browse/VELTOOLS-198
> Project: Velocity Tools
> Issue Type: Bug
> Components: GenericTools
>Affects Versions: 3.1
>Reporter: Oscar Doral
>Priority: Major
> Labels: pull-request-available
>
> org.apache.velocity.tools.ConversionUtils holds a cache for custom formats so
> it can reuse formatters across different requests:
> {code:java}
> private static ConcurrentMap customFormatsCache = new
> ConcurrentHashMap(); {code}
> Problem is formatters don't use to be thread safe so if same formatter is
> used at the same time by two different threads we can get errors depending on
> race conditions.
--
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] (VELTOOLS-198) org.apache.velocity.tools.ConversionUtils#getNumberFormat(java.lang.String, java.util.Locale) is not thread safe for custom formats
[
https://issues.apache.org/jira/browse/VELTOOLS-198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17630582#comment-17630582
]
Oscar Doral commented on VELTOOLS-198:
--
I've created a pull request with a solution to move from ConcurrentMap to
ThreadLocal [https://github.com/apache/velocity-tools/pull/12]
This way, formatters won't be shared between different threads.
> org.apache.velocity.tools.ConversionUtils#getNumberFormat(java.lang.String,
> java.util.Locale) is not thread safe for custom formats
> ---
>
> Key: VELTOOLS-198
> URL: https://issues.apache.org/jira/browse/VELTOOLS-198
> Project: Velocity Tools
> Issue Type: Bug
> Components: GenericTools
>Affects Versions: 3.1
>Reporter: Oscar Doral
>Priority: Major
> Labels: pull-request-available
>
> org.apache.velocity.tools.ConversionUtils holds a cache for custom formats so
> it can reuse formatters across different requests:
> {code:java}
> private static ConcurrentMap customFormatsCache = new
> ConcurrentHashMap(); {code}
> Problem is formatters don't use to be thread safe so if same formatter is
> used at the same time by two different threads we can get errors depending on
> race conditions.
--
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] (VELTOOLS-198) org.apache.velocity.tools.ConversionUtils#getNumberFormat(java.lang.String, java.util.Locale) is not thread safe for custom formats
[
https://issues.apache.org/jira/browse/VELTOOLS-198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oscar Doral updated VELTOOLS-198:
-
Labels: pull-request-available (was: )
> org.apache.velocity.tools.ConversionUtils#getNumberFormat(java.lang.String,
> java.util.Locale) is not thread safe for custom formats
> ---
>
> Key: VELTOOLS-198
> URL: https://issues.apache.org/jira/browse/VELTOOLS-198
> Project: Velocity Tools
> Issue Type: Bug
> Components: GenericTools
>Affects Versions: 3.1
>Reporter: Oscar Doral
>Priority: Major
> Labels: pull-request-available
>
> org.apache.velocity.tools.ConversionUtils holds a cache for custom formats so
> it can reuse formatters across different requests:
> {code:java}
> private static ConcurrentMap customFormatsCache = new
> ConcurrentHashMap(); {code}
> Problem is formatters don't use to be thread safe so if same formatter is
> used at the same time by two different threads we can get errors depending on
> race conditions.
--
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] (VELTOOLS-198) org.apache.velocity.tools.ConversionUtils#getNumberFormat(java.lang.String, java.util.Locale) is not thread safe for custom formats
Oscar Doral created VELTOOLS-198:
Summary:
org.apache.velocity.tools.ConversionUtils#getNumberFormat(java.lang.String,
java.util.Locale) is not thread safe for custom formats
Key: VELTOOLS-198
URL: https://issues.apache.org/jira/browse/VELTOOLS-198
Project: Velocity Tools
Issue Type: Bug
Components: GenericTools
Affects Versions: 3.1
Reporter: Oscar Doral
org.apache.velocity.tools.ConversionUtils holds a cache for custom formats so
it can reuse formatters across different requests:
{code:java}
private static ConcurrentMap customFormatsCache = new
ConcurrentHashMap(); {code}
Problem is formatters don't use to be thread safe so if same formatter is used
at the same time by two different threads we can get errors depending on race
conditions.
--
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] (VELTOOLS-197) xmlTool.find("./text()") (XPATH) not the same as xmlTool.getText () (METHOD) when & in text
[
https://issues.apache.org/jira/browse/VELTOOLS-197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
steven van vlierberghe updated VELTOOLS-197:
Description:
#foreach ($item2 in $xmlf1.find("/input/rep/x"))
xpath: ${item2.find("./text()")} xml: $item2.getText()
#end
with $xmlf1 an XmlTool instance initialized on the following inputfile:
{code:java}
R&R
R&B
{code}
using VeloctityTools-XmlTool 2.0 : find("./text()") returns same as getText()
for an xmlTool instance (and complying with the expectation)
{code:java}
xpath: R&R xml: R&R
xpath: R&B xml: R&B
{code}
However, using XmlTool 3.1, the xpath construct does not return the same as the
getText,
so the xpath does not comply with expectation
{code:java}
xpath: R&R xml: R&R
xpath: R&B xml: R&B
{code}
PS:
it can be solved in 3.1, by replacing $item2.find("./text()") by
$item2.find("./text()").node().getNodeValue()
BUT
this really requires to adapt the script
the actual problem is that I give support in our software to users for running
their own Velocity scripts in our software.
In the next version of our software, we upgraded Velocity + VelocityTools to
3.1
and as a consequence, scripts of the users might break;
meaning, this regression issue will impose our users to have to adapt their
scripts that are used in production
and for sure, they will not be happy having to do so
PS2: also have the impression that plainly rendering $item2.find("./text()") as
String also looses leading and trailing white space
was:
#foreach ($item2 in $xmlf1.find("/input/rep/x"))
xpath: ${item2.find("./text()")} xml: $item2.getText()
#end
with $xmlf1 an XmlTool instance initialized on the following inputfile:
{code:java}
R&R
R&B
{code}
using VeloctityTools-XmlTool 2.0 : find("./text()") returns same as getText()
for an xmlTool instance (and complying with the expectation)
{code:java}
xpath: R&R xml: R&R
xpath: R&B xml: R&B
{code}
However, using XmlTool 3.1, the xpath construct does not return the same as the
getText,
so the xpath does not comply with expectation
{code:java}
xpath: R&R xml: R&R
xpath: R&B xml: R&B
{code}
PS:
it can be solved in 3.1, by replacing $item2.find("./text()") by
$item2.find("./text()").node().getNodeValue()
BUT
this really requires to adapt the script
the actual problem is that I give support in our software to users for running
their own Velocity scripts in our software.
In the next version of our software, we upgraded Velocity + VelocityTools to
3.1
and as a consequence, scripts of the users might break;
meaning, this regression issue will impose our users to have to adapt their
scripts that are used in production
and for sure, they will not be happy having to do so
> xmlTool.find("./text()") (XPATH) not the same as xmlTool.getText () (METHOD)
> when & in text
> ---
>
> Key: VELTOOLS-197
> URL: https://issues.apache.org/jira/browse/VELTOOLS-197
> Project: Velocity Tools
> Issue Type: Bug
> Components: GenericTools
>Affects Versions: 3.1
>Reporter: steven van vlierberghe
>Priority: Major
>
> #foreach ($item2 in $xmlf1.find("/input/rep/x"))
> xpath: ${item2.find("./text()")} xml: $item2.getText()
> #end
> with $xmlf1 an XmlTool instance initialized on the following inputfile:
> {code:java}
>
>
> R&R
> R&B
>
>
> {code}
> using VeloctityTools-XmlTool 2.0 : find("./text()") returns same as
> getText() for an xmlTool instance (and complying with the expectation)
> {code:java}
> xpath: R&R xml: R&R
> xpath: R&B xml: R&B
> {code}
> However, using XmlTool 3.1, the xpath construct does not return the same as
> the getText,
> so the xpath does not comply with expectation
> {code:java}
> xpath: R&R xml: R&R
> xpath: R&B xml: R&B
> {code}
>
> PS:
> it can be solved in 3.1, by replacing $item2.find("./text()") by
> $item2.find("./text()").node().getNodeValue()
> BUT
> this really requires to adapt the script
> the actual problem is that I give support in our software to users for
> running their own Velocity scripts in our software.
> In the next version of our software, we upgraded Velocity + VelocityTools to
> 3.1
> and as a consequence, scripts of the users might break;
> meaning, this regression issue will impose our users to have to adapt their
> scripts tha
[jira] [Commented] (VELTOOLS-197) xmlTool.find("./text()") (XPATH) not the same as xmlTool.getText () (METHOD) when & in text
[
https://issues.apache.org/jira/browse/VELTOOLS-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17616394#comment-17616394
]
Michael Osipov commented on VELTOOLS-197:
-
Interesting, that seems odd!
> xmlTool.find("./text()") (XPATH) not the same as xmlTool.getText () (METHOD)
> when & in text
> ---
>
> Key: VELTOOLS-197
> URL: https://issues.apache.org/jira/browse/VELTOOLS-197
> Project: Velocity Tools
> Issue Type: Bug
> Components: GenericTools
>Affects Versions: 3.1
>Reporter: steven van vlierberghe
>Priority: Major
>
> #foreach ($item2 in $xmlf1.find("/input/rep/x"))
> xpath: ${item2.find("./text()")} xml: $item2.getText()
> #end
> with $xmlf1 an XmlTool instance initialized on the following inputfile:
> {code:java}
>
>
> R&R
> R&B
>
>
> {code}
> using VeloctityTools-XmlTool 2.0 : find("./text()") returns same as
> getText() for an xmlTool instance (and complying with the expectation)
> {code:java}
> xpath: R&R xml: R&R
> xpath: R&B xml: R&B
> {code}
> However, using XmlTool 3.1, the xpath construct does not return the same as
> the getText,
> so the xpath does not comply with expectation
> {code:java}
> xpath: R&R xml: R&R
> xpath: R&B xml: R&B
> {code}
>
> PS:
> it can be solved in 3.1, by replacing $item2.find("./text()") by
> $item2.find("./text()").node().getNodeValue()
> BUT
> this really requires to adapt the script
> the actual problem is that I give support in our software to users for
> running their own Velocity scripts in our software.
> In the next version of our software, we upgraded Velocity + VelocityTools to
> 3.1
> and as a consequence, scripts of the users might break;
> meaning, this regression issue will impose our users to have to adapt their
> scripts that are used in production
> and for sure, they will not be happy having to do so
--
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] (VELTOOLS-197) xmlTool.find("./text()") (XPATH) not the same as xmlTool.getText () (METHOD) when & in text
[
https://issues.apache.org/jira/browse/VELTOOLS-197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
steven van vlierberghe updated VELTOOLS-197:
Description:
#foreach ($item2 in $xmlf1.find("/input/rep/x"))
xpath: ${item2.find("./text()")} xml: $item2.getText()
#end
with $xmlf1 an XmlTool instance initialized on the following inputfile:
{code:java}
R&R
R&B
{code}
using VeloctityTools-XmlTool 2.0 : find("./text()") returns same as getText()
for an xmlTool instance (and complying with the expectation)
{code:java}
xpath: R&R xml: R&R
xpath: R&B xml: R&B
{code}
However, using XmlTool 3.1, the xpath construct does not return the same as the
getText,
so the xpath does not comply with expectation
{code:java}
xpath: R&R xml: R&R
xpath: R&B xml: R&B
{code}
PS:
it can be solved in 3.1, by replacing $item2.find("./text()") by
$item2.find("./text()").node().getNodeValue()
BUT
this really requires to adapt the script
the actual problem is that I give support in our software to users for running
their own Velocity scripts in our software.
In the next version of our software, we upgraded Velocity + VelocityTools to
3.1
and as a consequence, scripts of the users might break;
meaning, this regression issue will impose our users to have to adapt their
scripts that are used in production
and for sure, they will not be happy having to do so
was:
#foreach ($item2 in $xmlf1.find("/input/rep/x"))
xpath: ${item2.find("./text()")} xml: $item2.getText()
#end
with $xmlf1 an XmlTool instance initialized on the following inputfile:
{code:java}
R&R
R&B
{code}
using VeloctityTools-XmlTool 2.0 : find("./text()") returns same as getText()
for an xmlTool instance (and complying with the expectation)
{code:java}
xpath: R&R xml: R&R
xpath: R&B xml: R&B
{code}
However, using XmlTool 3.1, the xpath construct does not return the same as the
getText,
so the xpath does not comply with expectation
{code:java}
xpath: R&R xml: R&R
xpath: R&B xml: R&B
{code}
> xmlTool.find("./text()") (XPATH) not the same as xmlTool.getText () (METHOD)
> when & in text
> ---
>
> Key: VELTOOLS-197
> URL: https://issues.apache.org/jira/browse/VELTOOLS-197
> Project: Velocity Tools
> Issue Type: Bug
> Components: GenericTools
>Affects Versions: 3.1
>Reporter: steven van vlierberghe
>Priority: Major
>
> #foreach ($item2 in $xmlf1.find("/input/rep/x"))
> xpath: ${item2.find("./text()")} xml: $item2.getText()
> #end
> with $xmlf1 an XmlTool instance initialized on the following inputfile:
> {code:java}
>
>
> R&R
> R&B
>
>
> {code}
> using VeloctityTools-XmlTool 2.0 : find("./text()") returns same as
> getText() for an xmlTool instance (and complying with the expectation)
> {code:java}
> xpath: R&R xml: R&R
> xpath: R&B xml: R&B
> {code}
> However, using XmlTool 3.1, the xpath construct does not return the same as
> the getText,
> so the xpath does not comply with expectation
> {code:java}
> xpath: R&R xml: R&R
> xpath: R&B xml: R&B
> {code}
>
> PS:
> it can be solved in 3.1, by replacing $item2.find("./text()") by
> $item2.find("./text()").node().getNodeValue()
> BUT
> this really requires to adapt the script
> the actual problem is that I give support in our software to users for
> running their own Velocity scripts in our software.
> In the next version of our software, we upgraded Velocity + VelocityTools to
> 3.1
> and as a consequence, scripts of the users might break;
> meaning, this regression issue will impose our users to have to adapt their
> scripts that are used in production
> and for sure, they will not be happy having to do so
--
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] (VELTOOLS-197) xmlTool.find("./text()") (XPATH) not the same as xmlTool.getText () (METHOD) when & in text
steven van vlierberghe created VELTOOLS-197:
---
Summary: xmlTool.find("./text()") (XPATH) not the same as
xmlTool.getText () (METHOD) when & in text
Key: VELTOOLS-197
URL: https://issues.apache.org/jira/browse/VELTOOLS-197
Project: Velocity Tools
Issue Type: Bug
Components: GenericTools
Affects Versions: 3.1
Reporter: steven van vlierberghe
#foreach ($item2 in $xmlf1.find("/input/rep/x"))
xpath: ${item2.find("./text()")} xml: $item2.getText()
#end
with $xmlf1 an XmlTool instance initialized on the following inputfile:
{code:java}
R&R
R&B
{code}
using VeloctityTools-XmlTool 2.0 : find("./text()") returns same as getText()
for an xmlTool instance (and complying with the expectation)
{code:java}
xpath: R&R xml: R&R
xpath: R&B xml: R&B
{code}
However, using XmlTool 3.1, the xpath construct does not return the same as the
getText,
so the xpath does not comply with expectation
{code:java}
xpath: R&R xml: R&R
xpath: R&B xml: R&B
{code}
--
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] [Closed] (VELOCITY-954) spring-velocity-support involve CVE-2022-22965
[ https://issues.apache.org/jira/browse/VELOCITY-954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed VELOCITY-954. --- > spring-velocity-support involve CVE-2022-22965 > --- > > Key: VELOCITY-954 > URL: https://issues.apache.org/jira/browse/VELOCITY-954 > Project: Velocity > Issue Type: Bug >Affects Versions: 2.3 >Reporter: zhaizeyu >Priority: Major > > spring-velocity-support 2.3 contains passive dependencies spring-beans 5.3.4 > spring-beans involve vulnerabilities CVE-2022-22965,need to upgrade component > to fix the vulnerability -- 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] [Resolved] (VELOCITY-954) spring-velocity-support involve CVE-2022-22965
[ https://issues.apache.org/jira/browse/VELOCITY-954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] zhaizeyu resolved VELOCITY-954. --- Resolution: Done If the main software has no vulnerability, no handling is required. > spring-velocity-support involve CVE-2022-22965 > --- > > Key: VELOCITY-954 > URL: https://issues.apache.org/jira/browse/VELOCITY-954 > Project: Velocity > Issue Type: Bug >Affects Versions: 2.3 >Reporter: zhaizeyu >Priority: Major > > spring-velocity-support 2.3 contains passive dependencies spring-beans 5.3.4 > spring-beans involve vulnerabilities CVE-2022-22965,need to upgrade component > to fix the vulnerability -- 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] (VELTOOLS-195) ConversionTool is deprecated, but no alternative for toBoolean*() provided
[
https://issues.apache.org/jira/browse/VELTOOLS-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17570865#comment-17570865
]
Michael Osipov commented on VELTOOLS-195:
-
Fantastic, can't wait to make it happen with 3.2 and Doxia Sitetools.
> ConversionTool is deprecated, but no alternative for toBoolean*() provided
> --
>
> Key: VELTOOLS-195
> URL: https://issues.apache.org/jira/browse/VELTOOLS-195
> Project: Velocity Tools
> Issue Type: Bug
> Components: GenericTools
>Affects Versions: 3.1
>Reporter: Michael Osipov
>Assignee: Claude Brisson
>Priority: Major
> Fix For: 3.2
>
>
> The {{ConversionTool}} has been deprecated with multiple alternatives, but
> none for {{boolean}}. Thus, relying on {{toBoolean()}} will fail in the
> future. Provide a sane migration path.
--
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] [Resolved] (VELTOOLS-195) ConversionTool is deprecated, but no alternative for toBoolean*() provided
[
https://issues.apache.org/jira/browse/VELTOOLS-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson resolved VELTOOLS-195.
-
Fix Version/s: 3.2
Assignee: Claude Brisson
Resolution: Fixed
Fixed by commit 79842528.
toBoolean() belongs to the NumberTool. Until evidence to the contrary, booleans
*are* numbers.
> ConversionTool is deprecated, but no alternative for toBoolean*() provided
> --
>
> Key: VELTOOLS-195
> URL: https://issues.apache.org/jira/browse/VELTOOLS-195
> Project: Velocity Tools
> Issue Type: Bug
> Components: GenericTools
>Affects Versions: 3.1
>Reporter: Michael Osipov
>Assignee: Claude Brisson
>Priority: Major
> Fix For: 3.2
>
>
> The {{ConversionTool}} has been deprecated with multiple alternatives, but
> none for {{boolean}}. Thus, relying on {{toBoolean()}} will fail in the
> future. Provide a sane migration path.
--
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] (VELTOOLS-195) ConversionTool is deprecated, but no alternative for toBoolean*() provided
[
https://issues.apache.org/jira/browse/VELTOOLS-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17570751#comment-17570751
]
Michael Osipov commented on VELTOOLS-195:
-
[~cbrisson], can you give an advice? This is imporant to the next stack of the
entire Maven Site ecosystem.
> ConversionTool is deprecated, but no alternative for toBoolean*() provided
> --
>
> Key: VELTOOLS-195
> URL: https://issues.apache.org/jira/browse/VELTOOLS-195
> Project: Velocity Tools
> Issue Type: Bug
> Components: GenericTools
>Affects Versions: 3.1
>Reporter: Michael Osipov
>Priority: Major
>
> The {{ConversionTool}} has been deprecated with multiple alternatives, but
> non for {{boolean}}. Thus, relying on {{toBoolean()}} will fail in the
> future. Provide a sane migration path.
--
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] (VELTOOLS-195) ConversionTool is deprecated, but no alternative for toBoolean*() provided
[
https://issues.apache.org/jira/browse/VELTOOLS-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated VELTOOLS-195:
Description: The {{ConversionTool}} has been deprecated with multiple
alternatives, but none for {{boolean}}. Thus, relying on {{toBoolean()}} will
fail in the future. Provide a sane migration path. (was: The
{{ConversionTool}} has been deprecated with multiple alternatives, but non for
{{boolean}}. Thus, relying on {{toBoolean()}} will fail in the future. Provide
a sane migration path.)
> ConversionTool is deprecated, but no alternative for toBoolean*() provided
> --
>
> Key: VELTOOLS-195
> URL: https://issues.apache.org/jira/browse/VELTOOLS-195
> Project: Velocity Tools
> Issue Type: Bug
> Components: GenericTools
>Affects Versions: 3.1
>Reporter: Michael Osipov
>Priority: Major
>
> The {{ConversionTool}} has been deprecated with multiple alternatives, but
> none for {{boolean}}. Thus, relying on {{toBoolean()}} will fail in the
> future. Provide a sane migration path.
--
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] [Closed] (VELOCITY-958) Template should be cloneable
[ https://issues.apache.org/jira/browse/VELOCITY-958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed VELOCITY-958. --- > Template should be cloneable > > > Key: VELOCITY-958 > URL: https://issues.apache.org/jira/browse/VELOCITY-958 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.3 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Minor > Fix For: 2.4 > > > Templates should be cloneable, the clone() method returning a template with a > deep clone of the AST tree. > It allows for dynamic transformations of the AST tree which don't affect the > original template. > One use case is the translation of ASTText nodes. -- 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] [Closed] (VELOCITY-959) Ease subclassing of #parse and #include directives
[ https://issues.apache.org/jira/browse/VELOCITY-959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed VELOCITY-959. --- > Ease subclassing of #parse and #include directives > -- > > Key: VELOCITY-959 > URL: https://issues.apache.org/jira/browse/VELOCITY-959 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.3 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Minor > Fix For: 2.4 > > > The #include directive should expose a protected getResource() method and the > #parse directive a protected getTemplate() method so that it is easier to > customize their behavior in a user defined directive inheriting from them. -- 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] [Resolved] (VELOCITY-959) Ease subclassing of #parse and #include directives
[ https://issues.apache.org/jira/browse/VELOCITY-959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson resolved VELOCITY-959. - Fix Version/s: 2.4 Resolution: Fixed Done with commit 28c97b43 > Ease subclassing of #parse and #include directives > -- > > Key: VELOCITY-959 > URL: https://issues.apache.org/jira/browse/VELOCITY-959 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.3 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Minor > Fix For: 2.4 > > > The #include directive should expose a protected getResource() method and the > #parse directive a protected getTemplate() method so that it is easier to > customize their behavior in a user defined directive inheriting from them. -- 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-959) Ease subclassing of #parse and #include directives
Claude Brisson created VELOCITY-959: --- Summary: Ease subclassing of #parse and #include directives Key: VELOCITY-959 URL: https://issues.apache.org/jira/browse/VELOCITY-959 Project: Velocity Issue Type: Improvement Components: Engine Affects Versions: 2.3 Reporter: Claude Brisson Assignee: Claude Brisson The #include directive should expose a protected getResource() method and the #parse directive a protected getTemplate() method so that it is easier to customize their behavior in a user defined directive inheriting from them. -- 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] [Resolved] (VELOCITY-958) Template should be cloneable
[ https://issues.apache.org/jira/browse/VELOCITY-958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson resolved VELOCITY-958. - Fix Version/s: 2.4 Resolution: Fixed Added in commit 051f20a8 > Template should be cloneable > > > Key: VELOCITY-958 > URL: https://issues.apache.org/jira/browse/VELOCITY-958 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.3 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Minor > Fix For: 2.4 > > > Templates should be cloneable, the clone() method returning a template with a > deep clone of the AST tree. > It allows for dynamic transformations of the AST tree which don't affect the > original template. > One use case is the translation of ASTText nodes. -- 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-958) Template should be cloneable
Claude Brisson created VELOCITY-958: --- Summary: Template should be cloneable Key: VELOCITY-958 URL: https://issues.apache.org/jira/browse/VELOCITY-958 Project: Velocity Issue Type: Improvement Components: Engine Affects Versions: 2.3 Reporter: Claude Brisson Assignee: Claude Brisson Templates should be cloneable, the clone() method returning a template with a deep clone of the AST tree. It allows for dynamic transformations of the AST tree which don't affect the original template. One use case is the translation of ASTText nodes. -- 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-957) Unexpected compare result
[
https://issues.apache.org/jira/browse/VELOCITY-957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17558409#comment-17558409
]
Michael Osipov commented on VELOCITY-957:
-
Interesting...we need to check the type coercion. Both should be string, thus
false.
> Unexpected compare result
> -
>
> Key: VELOCITY-957
> URL: https://issues.apache.org/jira/browse/VELOCITY-957
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Kai Bächle
>Priority: Major
>
> {code:java}
> #if('1' == '1.0')same#{else}different#end {code}
> has "same" as result using velocity 2.3 and "different" using 1.7
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Created] (VELOCITY-957) Unexpected compare result
Kai Bächle created VELOCITY-957:
---
Summary: Unexpected compare result
Key: VELOCITY-957
URL: https://issues.apache.org/jira/browse/VELOCITY-957
Project: Velocity
Issue Type: Bug
Components: Engine
Affects Versions: 2.3
Reporter: Kai Bächle
{code:java}
#if('1' == '1.0')same#{else}different#end {code}
has "same" as result using velocity 2.3 and "different" using 1.7
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELTOOLS-196) MathTool.matchType can truncate integral values
[ https://issues.apache.org/jira/browse/VELTOOLS-196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Schultz updated VELTOOLS-196: - Description: I found this while trying to create random numbers with a huge range. Without thinking too hard about it, I did: $math.random(1,) That's 20 nines all lined-up, which turns out to be larger than Long.MAX_VALUE. The result is that my random number is _always_ Long.MAX_VALUE. I tracked this down to MathTool.random's use of MathTool.matchType, which returns either an Integer or a Long value, depending upon whether the value-to-match-types is outside the range of [ Integer.MIN_VALUE - Integer.MAX_VALUE ]. Well, there are double values which are higher than Long.MAX_VALUE, too, and those should return a BigInteger value instead of a Long. If I call $math.toNumber(), I get a BigInteger and so I'd expect that MathTool.random() would be able to return a BigInteger as well. So I think we just need another clause which checks to see if Long isn't big enough, and return a BigInteger instead. (We might want to think about supporting BigDouble, too, but that's outside the scope of this bug report.) was: I found this while trying to create random numbers with a huge range. Without thinking too hard about it, I did: $math.random(1,) That's 20 nines all lined-up, which turns out to be larger than Long.MAX_VALUE. The result is that my random number is always Long.MAX_DOUBLE. I tracked this down to MathTool.random's use of MathTool.matchTypes, which returns either an Integer or a Long value, depending upon whether the value-to-match-types is outside the range of [ Integer.MIN_VALUE - Integer.MAX_VALUE ]. Well, there are double values which are higher than Long.MAX_VALUE, too, and those should return a BigInteger value instead of a Long. If I call $math.toNumber(), I get a BigInteger and so I'd expect that MathTool.random() would be able to return a BigInteger as well. So I think we just need another clause which checks to see if Long isn't big enough, and return a BigInteger instead. (We might want to think about supporting BigDouble, too, but that's outside the scope of this bug report.) > MathTool.matchType can truncate integral values > --- > > Key: VELTOOLS-196 > URL: https://issues.apache.org/jira/browse/VELTOOLS-196 > Project: Velocity Tools > Issue Type: Bug >Affects Versions: 3.1 >Reporter: Christopher Schultz >Priority: Minor > > I found this while trying to create random numbers with a huge range. Without > thinking too hard about it, I did: > $math.random(1,) > That's 20 nines all lined-up, which turns out to be larger than > Long.MAX_VALUE. The result is that my random number is _always_ > Long.MAX_VALUE. > I tracked this down to MathTool.random's use of MathTool.matchType, which > returns either an Integer or a Long value, depending upon whether the > value-to-match-types is outside the range of [ Integer.MIN_VALUE - > Integer.MAX_VALUE ]. > Well, there are double values which are higher than Long.MAX_VALUE, too, and > those should return a BigInteger value instead of a Long. > If I call $math.toNumber(), I get a BigInteger and so I'd > expect that MathTool.random() would be able to return a BigInteger as well. > So I think we just need another clause which checks to see if Long isn't big > enough, and return a BigInteger instead. > (We might want to think about supporting BigDouble, too, but that's outside > the scope of this bug report.) -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Created] (VELTOOLS-196) MathTool.matchType can truncate integral values
Christopher Schultz created VELTOOLS-196: Summary: MathTool.matchType can truncate integral values Key: VELTOOLS-196 URL: https://issues.apache.org/jira/browse/VELTOOLS-196 Project: Velocity Tools Issue Type: Bug Affects Versions: 3.1 Reporter: Christopher Schultz I found this while trying to create random numbers with a huge range. Without thinking too hard about it, I did: $math.random(1,) That's 20 nines all lined-up, which turns out to be larger than Long.MAX_VALUE. The result is that my random number is always Long.MAX_DOUBLE. I tracked this down to MathTool.random's use of MathTool.matchTypes, which returns either an Integer or a Long value, depending upon whether the value-to-match-types is outside the range of [ Integer.MIN_VALUE - Integer.MAX_VALUE ]. Well, there are double values which are higher than Long.MAX_VALUE, too, and those should return a BigInteger value instead of a Long. If I call $math.toNumber(), I get a BigInteger and so I'd expect that MathTool.random() would be able to return a BigInteger as well. So I think we just need another clause which checks to see if Long isn't big enough, and return a BigInteger instead. (We might want to think about supporting BigDouble, too, but that's outside the scope of this bug report.) -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Created] (VELTOOLS-195) ConversionTool is deprecated, but no alternative for toBoolean*() provided
Michael Osipov created VELTOOLS-195:
---
Summary: ConversionTool is deprecated, but no alternative for
toBoolean*() provided
Key: VELTOOLS-195
URL: https://issues.apache.org/jira/browse/VELTOOLS-195
Project: Velocity Tools
Issue Type: Bug
Components: GenericTools
Affects Versions: 3.1
Reporter: Michael Osipov
The {{ConversionTool}} has been deprecated with multiple alternatives, but non
for {{boolean}}. Thus, relying on {{toBoolean()}} will fail in the future.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELTOOLS-195) ConversionTool is deprecated, but no alternative for toBoolean*() provided
[
https://issues.apache.org/jira/browse/VELTOOLS-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated VELTOOLS-195:
Description: The {{ConversionTool}} has been deprecated with multiple
alternatives, but non for {{boolean}}. Thus, relying on {{toBoolean()}} will
fail in the future. Provide a sane migration path. (was: The
{{ConversionTool}} has been deprecated with multiple alternatives, but non for
{{boolean}}. Thus, relying on {{toBoolean()}} will fail in the future.)
> ConversionTool is deprecated, but no alternative for toBoolean*() provided
> --
>
> Key: VELTOOLS-195
> URL: https://issues.apache.org/jira/browse/VELTOOLS-195
> Project: Velocity Tools
> Issue Type: Bug
> Components: GenericTools
>Affects Versions: 3.1
>Reporter: Michael Osipov
>Priority: Major
>
> The {{ConversionTool}} has been deprecated with multiple alternatives, but
> non for {{boolean}}. Thus, relying on {{toBoolean()}} will fail in the
> future. Provide a sane migration path.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-955) velocity 1.7 vs velocity 2.3 : the evaluation of if condition in script is different
[
https://issues.apache.org/jira/browse/VELOCITY-955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ambika updated VELOCITY-955:
Description:
*script used :*
Map variables = new HashMap<>();
variables.put("key1", "value");
Context context = velocityEngine.getToolsContext(variables);
String inString = "#set($value = \"key value false\")" +
"#if(${key1} == 1 ||\"yes\" )" +
" #set($value = \"{*}{{*}}key value true{{*}}{*}\")" +
"#end\n${value}";
inString = velocityEngine.evaluate(context, "tag", inString);
System.out.println(inString);
Output:
older version output : key value true
newer version output : key value false
was:
*script used :*
Map variables = new HashMap<>();
variables.put("key1", "value");
Context context = velocityEngine.getToolsContext(variables);
String inString = "#set($value = \"key value false\")" +
"#if(${key1} == 1 ||\"yes\" )" +
" #set($value = \"*{*}key value true{*}*\")" +
"#end\n${value}";
inString = velocityManager.evaluate(context, "tag", inString);
System.out.println(inString);
Output:
older version output : key value true
newer version output : key value false
> velocity 1.7 vs velocity 2.3 : the evaluation of if condition in script is
> different
> -
>
> Key: VELOCITY-955
> URL: https://issues.apache.org/jira/browse/VELOCITY-955
> Project: Velocity
> Issue Type: Bug
> Components: Scripting
>Affects Versions: 2.3
>Reporter: ambika
>Priority: Major
>
> *script used :*
>
> Map variables = new HashMap<>();
> variables.put("key1", "value");
>
> Context context = velocityEngine.getToolsContext(variables);
>
> String inString = "#set($value = \"key value false\")" +
> "#if(${key1} == 1 ||\"yes\" )" +
> " #set($value = \"{*}{{*}}key value true{{*}}{*}\")" +
> "#end\n${value}";
>
> inString = velocityEngine.evaluate(context, "tag", inString);
> System.out.println(inString);
>
>
> Output:
>
> older version output : key value true
>
> newer version output : key value false
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
