[jira] [Commented] (VELOCITY-984) Velocity calls method of abstract superclass leading to an IllegalAccessException
[
https://issues.apache.org/jira/browse/VELOCITY-984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887775#comment-17887775
]
Claude Brisson commented on VELOCITY-984:
-
This is better than nothing, hopefully this is cached, because throw/catch
mechanisms are slow. Maybe we could resort to Java 9+ {{canAccess()}} when
possible, and to {{isAccessible()}} on Java 8.
> Velocity calls method of abstract superclass leading to an
> IllegalAccessException
> -
>
> Key: VELOCITY-984
> URL: https://issues.apache.org/jira/browse/VELOCITY-984
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.4
>Reporter: Christoph Lenggenhager
>Assignee: Claude Brisson
>Priority: Major
> Attachments: Velocity952TestCase.java
>
>
> With the changes introduced in VELOCITY-952, our templates fail with an
> IllegalAccessException.
> The exception is caused by a template that has a variable of type
> StringBuilder and calls append on it. The introduced changes choose the
> implementation of the method of AbstractStringBuilder to be executed, which
> leads to the mentioned IllegalAccessExceptions.
> I've attached an extended version of Velocity952TestCase.java that reproduces
> the problem with an additional test.
>
--
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-984) Velocity calls method of abstract superclass leading to an IllegalAccessException
[ https://issues.apache.org/jira/browse/VELOCITY-984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson reassigned VELOCITY-984: --- Assignee: Claude Brisson > Velocity calls method of abstract superclass leading to an > IllegalAccessException > - > > Key: VELOCITY-984 > URL: https://issues.apache.org/jira/browse/VELOCITY-984 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.4 >Reporter: Christoph Lenggenhager >Assignee: Claude Brisson >Priority: Major > Attachments: Velocity952TestCase.java > > > With the changes introduced in VELOCITY-952, our templates fail with an > IllegalAccessException. > The exception is caused by a template that has a variable of type > StringBuilder and calls append on it. The introduced changes choose the > implementation of the method of AbstractStringBuilder to be executed, which > leads to the mentioned IllegalAccessExceptions. > I've attached an extended version of Velocity952TestCase.java that reproduces > the problem with an additional test. > -- 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-984) Velocity calls method of abstract superclass leading to an IllegalAccessException
[ https://issues.apache.org/jira/browse/VELOCITY-984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887087#comment-17887087 ] Claude Brisson commented on VELOCITY-984: - Yes [~tmortagne] you are certainly right, it will have less side effects. Do you think you could provide a patch? > Velocity calls method of abstract superclass leading to an > IllegalAccessException > - > > Key: VELOCITY-984 > URL: https://issues.apache.org/jira/browse/VELOCITY-984 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.4 >Reporter: Christoph Lenggenhager >Priority: Major > Attachments: Velocity952TestCase.java > > > With the changes introduced in VELOCITY-952, our templates fail with an > IllegalAccessException. > The exception is caused by a template that has a variable of type > StringBuilder and calls append on it. The introduced changes choose the > implementation of the method of AbstractStringBuilder to be executed, which > leads to the mentioned IllegalAccessExceptions. > I've attached an extended version of Velocity952TestCase.java that reproduces > the problem with an additional test. > -- 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-983) Velocity calls the wrong static "overwritten" method
[ https://issues.apache.org/jira/browse/VELOCITY-983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson closed VELOCITY-983. --- Fix Version/s: 2.4.1 Assignee: Claude Brisson Resolution: Fixed PR merged. Thanks, [~tmortagne] . > Velocity calls the wrong static "overwritten" method > > > Key: VELOCITY-983 > URL: https://issues.apache.org/jira/browse/VELOCITY-983 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.4 >Reporter: Thomas Mortagne >Assignee: Claude Brisson >Priority: Blocker > Fix For: 2.4.1 > > > Unfortunately, in my proposal in VELOCITY-952 I totally missed one use case > which is now broken: a static method being "overwritten". Since Velocity 2.4, > the deepest static method will be called instead of the one in the object we > actually manipulate and unfortunately since static overrides are not real > overrides it means it's going to call the wrong one. > The reason [the uberspector I was using with Velocity > 2.3|https://github.com/xwiki/xwiki-commons/blob/a21846242821db564378bb68b1060fa42c632d16/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodOverrideUberspector.java#L116] > was not impacted is because I had an optimization to stop searching when > hitting the first accessible method (since my focus was > IllegalAccessException problems). -- 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-981) Upgrade to Parent 7
[ https://issues.apache.org/jira/browse/VELOCITY-981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson updated VELOCITY-981: Fix Version/s: (was: 2.4.2) > Upgrade to Parent 7 > --- > > Key: VELOCITY-981 > URL: https://issues.apache.org/jira/browse/VELOCITY-981 > Project: Velocity > Issue Type: Task > Components: Build >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 2.4 > > -- 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-977) Upgrade Java Compiler Compiler to Version 7.0.13
[ https://issues.apache.org/jira/browse/VELOCITY-977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson updated VELOCITY-977: Fix Version/s: (was: 2.4.2) > Upgrade Java Compiler Compiler to Version 7.0.13 > > > Key: VELOCITY-977 > URL: https://issues.apache.org/jira/browse/VELOCITY-977 > Project: Velocity > Issue Type: Improvement >Reporter: Sylwester Lachiewicz >Assignee: Michael Osipov >Priority: Minor > Fix For: 2.4 > > -- 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-951) DataSourceResourceLoader: property datasource_url wrong
[
https://issues.apache.org/jira/browse/VELOCITY-951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson updated VELOCITY-951:
Fix Version/s: (was: 2.4.1)
(was: 2.4.2)
> DataSourceResourceLoader: property datasource_url wrong
> ---
>
> Key: VELOCITY-951
> URL: https://issues.apache.org/jira/browse/VELOCITY-951
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Andreas Sachs
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 2.4
>
>
> According to the javadoc it's
> resource.loader.ds.{*}resource.{*}datasource_url =
> java:comp/env/jdbc/Velocity
> resource.loader.ds.resource.table = tb_velocity_template
>
> But in the implementation "resource" is missing (only for datasource_url):
> dataSourceName = StringUtils.trim(configuration.getString("datasource_url"));
> tableName = StringUtils.trim(configuration.getString("resource.table"));
>
--
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-972) Remove Commons IO
[ https://issues.apache.org/jira/browse/VELOCITY-972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson updated VELOCITY-972: Fix Version/s: (was: 2.4.1) (was: 2.4.2) > Remove Commons IO > - > > Key: VELOCITY-972 > URL: https://issues.apache.org/jira/browse/VELOCITY-972 > Project: Velocity > Issue Type: Task > Components: Build, Engine >Affects Versions: 2.3 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 2.4 > > > There are only a few spots where Commons IO is used. These can be removed for > the two reasons: > * Replace with NIO2 methods > * Take input as-is since behavior has never been part of the contract > (Javadoc) -- 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-973) Upgrade dependencies
[ https://issues.apache.org/jira/browse/VELOCITY-973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson updated VELOCITY-973: Fix Version/s: (was: 2.4.1) (was: 2.4.2) > Upgrade dependencies > > > Key: VELOCITY-973 > URL: https://issues.apache.org/jira/browse/VELOCITY-973 > Project: Velocity > Issue Type: Task >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 2.4 > > > * Upgrade to SLF4J 1.7.36 > * Upgrade to Commons Lang 3.14.0 > * Upgrade to Spring Framework 5.3.31 > * Upgrade to HSQLDB 2.7.2 -- 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-974) Use non-deprecated config property for resource loaders in VelocityEngineFactory
[ https://issues.apache.org/jira/browse/VELOCITY-974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson updated VELOCITY-974: Fix Version/s: (was: 2.4.1) (was: 2.4.2) > Use non-deprecated config property for resource loaders in > VelocityEngineFactory > > > Key: VELOCITY-974 > URL: https://issues.apache.org/jira/browse/VELOCITY-974 > Project: Velocity > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 2.4 > > -- 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-958) Template should be cloneable
[ https://issues.apache.org/jira/browse/VELOCITY-958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson updated VELOCITY-958: Fix Version/s: (was: 2.4.1) (was: 2.4.2) > 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] [Updated] (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 updated VELOCITY-940:
Fix Version/s: (was: 2.4.1)
(was: 2.4.2)
> 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] [Updated] (VELOCITY-970) velocity-engine-core contains commons-io Maven descriptor
[ https://issues.apache.org/jira/browse/VELOCITY-970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson updated VELOCITY-970: Fix Version/s: (was: 2.4.1) (was: 2.4.2) > velocity-engine-core contains commons-io Maven descriptor > - > > Key: VELOCITY-970 > URL: https://issues.apache.org/jira/browse/VELOCITY-970 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.3 >Reporter: Thomas Mortagne >Assignee: Michael Osipov >Priority: Major > Fix For: 2.4 > > > commons-io is embedded in velocity-engine-core, which is OK from Java point > of view since its package is renamed (not causing any dependency problems). > The problem is that it contains the commons-io Maven descriptors at the > standard location (/META-INF/maven/commons-io/commons-io/), which is a > problem when you analyze JAR files to find what's in it because it ends up > being identified as a JAR exposing commons-io (which is not the case since > it's weaved). > Honestly, it feels very strange to embed commons-io in the first place given > that commons-lang for example is a transitive dependency, so I feel like the > simplest would just be to remove all the plumbing to embed and weave > commons-io and simply keep it as a regular transitive dependency. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-971) Upgrade to Parent 6
[ https://issues.apache.org/jira/browse/VELOCITY-971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson updated VELOCITY-971: Fix Version/s: (was: 2.4.1) (was: 2.4.2) > Upgrade to Parent 6 > --- > > Key: VELOCITY-971 > URL: https://issues.apache.org/jira/browse/VELOCITY-971 > Project: Velocity > Issue Type: Improvement > Components: Build >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 2.4 > > > Parent 6 gives us the ability to clean up a lot of duplicate stuff in our > POMs. -- 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-981) Upgrade to Parent 7
[ https://issues.apache.org/jira/browse/VELOCITY-981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson updated VELOCITY-981: Fix Version/s: 2.4 > Upgrade to Parent 7 > --- > > Key: VELOCITY-981 > URL: https://issues.apache.org/jira/browse/VELOCITY-981 > Project: Velocity > Issue Type: Task > Components: Build >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 2.4, 2.4.2 > > -- 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-943) File vs. classpath issues with Spring VelocityEngineFactory
[ https://issues.apache.org/jira/browse/VELOCITY-943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson resolved VELOCITY-943. - Fix Version/s: 2.4 Assignee: Claude Brisson Resolution: Fixed PR merged > File vs. classpath issues with Spring VelocityEngineFactory > --- > > Key: VELOCITY-943 > URL: https://issues.apache.org/jira/browse/VELOCITY-943 > Project: Velocity > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Scott Cantor >Assignee: Claude Brisson >Priority: Minor > Labels: spring > Fix For: 2.4 > > Attachments: VelocityEngineFactory.java > > > TL;DR, there's a nominal bug fix, and a possible improvement I can suggest, > for the Spring support you copied in from Spring 4 based on the copy we're > using in our project. Our copy differs in some slight ways so a straight > patch diff wasn't very obvious and I'm just going to attach our copy of the > file. > Full explanation: we ported the Spring support into our code for Spring 5 > before you had ported it in, and we were actually prepping a submission for > that but you pulled it in before we had a chance. There were some slight > improvements I made for our use, and today another issue in the same area of > the code got reported and fixed, and it's nominally a bug, so I thought I'd > try submitting that as a possible improvement along with my other change. > The issue is mainly around the way the Spring code combined use of the > File-based Velocity loader with the Spring loader by checking for filesystem > existence on the paths, in order to allow file-based usage to leverage > Velocity's support for template reloading. > In Spring's code (and now your code), there's an issue because it processes > each path via Spring ResourceLoader and then converts the Resource into a > File for an exists() test. If that passes, it installs the file-based loader > instead of the Spring loader. The problem/bug is that some containers unpack > jars, but only partially. Some kind of weird optimization I guess. The result > is that if some of the files get unpacked and not others, this code installs > the file loader and then that fails later because not all the files are there. > The fix seems to be to check for classpath: leading off the path and skip the > exists() check so that it will get deferred to the Spring loader. So that's a > fix, nominally, though right now we've only seen this reported for Wildfly as > a container. > The related enhancement I made was that I allowed for both File-based and > Spring-based paths by walking the complete list and tracking each path set > individually and allowing both loaders to get installed into the Velocity > engine. That was needed for us to support both file-based templates along > with system templates we ship in jars. So as it, we have to have that feature > and can't use the original Spring code, so I'm hoping with the possible > justification of a bug fix, you might take the other change also. > All of the differences that aren't cosmetic are in the > initVelocityResourceLoader method, except that there's also a fix to > initSpringResourceLoader that changes a setProperty to addProperty so that > the Spring loader can get added to the set of loaders and not replace the > file loader. > Apologies that a diff would be so messy but hopefully given that the class is > simple and small, the differences will be clear enough with my explanation. -- 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-943) File vs. classpath issues with Spring VelocityEngineFactory
[ https://issues.apache.org/jira/browse/VELOCITY-943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17879112#comment-17879112 ] Claude Brisson commented on VELOCITY-943: - Thanks for your remarks. Regarding VelocityView and ViewResolver, they should be part of a new module in the tools subproject, velocity-tools-spring or alike... Yes, only having the spring specialization for the engine itself is half of what's needed. > File vs. classpath issues with Spring VelocityEngineFactory > --- > > Key: VELOCITY-943 > URL: https://issues.apache.org/jira/browse/VELOCITY-943 > Project: Velocity > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Scott Cantor >Priority: Minor > Labels: spring > Attachments: VelocityEngineFactory.java > > > TL;DR, there's a nominal bug fix, and a possible improvement I can suggest, > for the Spring support you copied in from Spring 4 based on the copy we're > using in our project. Our copy differs in some slight ways so a straight > patch diff wasn't very obvious and I'm just going to attach our copy of the > file. > Full explanation: we ported the Spring support into our code for Spring 5 > before you had ported it in, and we were actually prepping a submission for > that but you pulled it in before we had a chance. There were some slight > improvements I made for our use, and today another issue in the same area of > the code got reported and fixed, and it's nominally a bug, so I thought I'd > try submitting that as a possible improvement along with my other change. > The issue is mainly around the way the Spring code combined use of the > File-based Velocity loader with the Spring loader by checking for filesystem > existence on the paths, in order to allow file-based usage to leverage > Velocity's support for template reloading. > In Spring's code (and now your code), there's an issue because it processes > each path via Spring ResourceLoader and then converts the Resource into a > File for an exists() test. If that passes, it installs the file-based loader > instead of the Spring loader. The problem/bug is that some containers unpack > jars, but only partially. Some kind of weird optimization I guess. The result > is that if some of the files get unpacked and not others, this code installs > the file loader and then that fails later because not all the files are there. > The fix seems to be to check for classpath: leading off the path and skip the > exists() check so that it will get deferred to the Spring loader. So that's a > fix, nominally, though right now we've only seen this reported for Wildfly as > a container. > The related enhancement I made was that I allowed for both File-based and > Spring-based paths by walking the complete list and tracking each path set > individually and allowing both loaders to get installed into the Velocity > engine. That was needed for us to support both file-based templates along > with system templates we ship in jars. So as it, we have to have that feature > and can't use the original Spring code, so I'm hoping with the possible > justification of a bug fix, you might take the other change also. > All of the differences that aren't cosmetic are in the > initVelocityResourceLoader method, except that there's also a fix to > initSpringResourceLoader that changes a setProperty to addProperty so that > the Spring loader can get added to the set of loaders and not replace the > file loader. > Apologies that a diff would be so messy but hopefully given that the class is > simple and small, the differences will be clear enough with my explanation. -- 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-943) File vs. classpath issues with Spring VelocityEngineFactory
[ https://issues.apache.org/jira/browse/VELOCITY-943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17879027#comment-17879027 ] Claude Brisson commented on VELOCITY-943: - Thanks for your prompt answer and contribution. Would that make sense and bring simplicity to handle that specific distinguo between file entries and classpath entries by means of having two distinct resource loaders, one explicitly searching for files and the other for classpath entries? > File vs. classpath issues with Spring VelocityEngineFactory > --- > > Key: VELOCITY-943 > URL: https://issues.apache.org/jira/browse/VELOCITY-943 > Project: Velocity > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Scott Cantor >Priority: Minor > Labels: spring > Attachments: VelocityEngineFactory.java > > > TL;DR, there's a nominal bug fix, and a possible improvement I can suggest, > for the Spring support you copied in from Spring 4 based on the copy we're > using in our project. Our copy differs in some slight ways so a straight > patch diff wasn't very obvious and I'm just going to attach our copy of the > file. > Full explanation: we ported the Spring support into our code for Spring 5 > before you had ported it in, and we were actually prepping a submission for > that but you pulled it in before we had a chance. There were some slight > improvements I made for our use, and today another issue in the same area of > the code got reported and fixed, and it's nominally a bug, so I thought I'd > try submitting that as a possible improvement along with my other change. > The issue is mainly around the way the Spring code combined use of the > File-based Velocity loader with the Spring loader by checking for filesystem > existence on the paths, in order to allow file-based usage to leverage > Velocity's support for template reloading. > In Spring's code (and now your code), there's an issue because it processes > each path via Spring ResourceLoader and then converts the Resource into a > File for an exists() test. If that passes, it installs the file-based loader > instead of the Spring loader. The problem/bug is that some containers unpack > jars, but only partially. Some kind of weird optimization I guess. The result > is that if some of the files get unpacked and not others, this code installs > the file loader and then that fails later because not all the files are there. > The fix seems to be to check for classpath: leading off the path and skip the > exists() check so that it will get deferred to the Spring loader. So that's a > fix, nominally, though right now we've only seen this reported for Wildfly as > a container. > The related enhancement I made was that I allowed for both File-based and > Spring-based paths by walking the complete list and tracking each path set > individually and allowing both loaders to get installed into the Velocity > engine. That was needed for us to support both file-based templates along > with system templates we ship in jars. So as it, we have to have that feature > and can't use the original Spring code, so I'm hoping with the possible > justification of a bug fix, you might take the other change also. > All of the differences that aren't cosmetic are in the > initVelocityResourceLoader method, except that there's also a fix to > initSpringResourceLoader that changes a setProperty to addProperty so that > the Spring loader can get added to the set of loaders and not replace the > file loader. > Apologies that a diff would be so messy but hopefully given that the class is > simple and small, the differences will be clear enough with my explanation. -- 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-943) File vs. classpath issues with Spring VelocityEngineFactory
[ https://issues.apache.org/jira/browse/VELOCITY-943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878417#comment-17878417 ] Claude Brisson commented on VELOCITY-943: - Do you know when you will be able to provide this patch? We have a release in the pipe, should we wait for it? > File vs. classpath issues with Spring VelocityEngineFactory > --- > > Key: VELOCITY-943 > URL: https://issues.apache.org/jira/browse/VELOCITY-943 > Project: Velocity > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Scott Cantor >Priority: Minor > Labels: spring > Attachments: VelocityEngineFactory.java > > > TL;DR, there's a nominal bug fix, and a possible improvement I can suggest, > for the Spring support you copied in from Spring 4 based on the copy we're > using in our project. Our copy differs in some slight ways so a straight > patch diff wasn't very obvious and I'm just going to attach our copy of the > file. > Full explanation: we ported the Spring support into our code for Spring 5 > before you had ported it in, and we were actually prepping a submission for > that but you pulled it in before we had a chance. There were some slight > improvements I made for our use, and today another issue in the same area of > the code got reported and fixed, and it's nominally a bug, so I thought I'd > try submitting that as a possible improvement along with my other change. > The issue is mainly around the way the Spring code combined use of the > File-based Velocity loader with the Spring loader by checking for filesystem > existence on the paths, in order to allow file-based usage to leverage > Velocity's support for template reloading. > In Spring's code (and now your code), there's an issue because it processes > each path via Spring ResourceLoader and then converts the Resource into a > File for an exists() test. If that passes, it installs the file-based loader > instead of the Spring loader. The problem/bug is that some containers unpack > jars, but only partially. Some kind of weird optimization I guess. The result > is that if some of the files get unpacked and not others, this code installs > the file loader and then that fails later because not all the files are there. > The fix seems to be to check for classpath: leading off the path and skip the > exists() check so that it will get deferred to the Spring loader. So that's a > fix, nominally, though right now we've only seen this reported for Wildfly as > a container. > The related enhancement I made was that I allowed for both File-based and > Spring-based paths by walking the complete list and tracking each path set > individually and allowing both loaders to get installed into the Velocity > engine. That was needed for us to support both file-based templates along > with system templates we ship in jars. So as it, we have to have that feature > and can't use the original Spring code, so I'm hoping with the possible > justification of a bug fix, you might take the other change also. > All of the differences that aren't cosmetic are in the > initVelocityResourceLoader method, except that there's also a fix to > initSpringResourceLoader that changes a setProperty to addProperty so that > the Spring loader can get added to the set of loaders and not replace the > file loader. > Apologies that a diff would be so messy but hopefully given that the class is > simple and small, the differences will be clear enough with my explanation. -- 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-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
]
Claude Brisson closed VELOCITY-965.
---
Fix Version/s: 2.4
Assignee: Claude Brisson
Resolution: Fixed
See commit 6c85ffe2
> 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
>Assignee: Claude Brisson
>Priority: Major
> Fix For: 2.4
>
>
> 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] [Closed] (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
]
Claude Brisson closed VELOCITY-966.
---
Resolution: Not A Bug
> 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
>Assignee: Claude Brisson
>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] [Commented] (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:comment-tabpanel&focusedCommentId=17878307#comment-17878307
]
Claude Brisson commented on VELOCITY-966:
-
I admit that the API is far from perfect, mostly because of backward
compatibility issues.
But the RuntimeInstance.render() method is *not* meant for a reuse of the AST
tree. I will add it to the doc.
What you should do, instead, is rely on the Resource and Template API, as
follow:
{code}
final RuntimeInstance runtimeInstance = new RuntimeInstance();
final VelocityContext context = new VelocityContext();
context.put("user", "abc");
final Template aTemplate = new Template();
aTemplate.setName("a_template");
aTemplate.setRuntimeServices(runtimeInstance);
final SimpleNode parsedTemplate = runtimeInstance.parse(new
StringReader("Hello $user !!!"), aTemplate);
aTemplate.setData(parsedTemplate);
aTemplate.initDocument();
//first time using parsed template
final StringWriter writer = new StringWriter();
aTemplate.merge(context, writer);
System.out.println(writer);
//second time using parsed template
final StringWriter writer2 = new StringWriter();
aTemplate.merge(context, writer2);
System.out.println(writer2);
{code}
> 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
>Assignee: Claude Brisson
>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] [Reopened] (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
]
Claude Brisson reopened VELOCITY-966:
-
Assignee: Claude Brisson
> 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
>Assignee: Claude Brisson
>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] [Closed] (VELOCITY-952) Velocity is calling the "wrong" method
[
https://issues.apache.org/jira/browse/VELOCITY-952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson closed VELOCITY-952.
---
Fix Version/s: 2.4
Assignee: Claude Brisson
Resolution: Fixed
> 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
>Assignee: Claude Brisson
>Priority: Major
> Fix For: 2.4
>
>
> 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.refledact.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=17876636#comment-17876636
]
Claude Brisson commented on VELOCITY-952:
-
The fix in ready for review [in this
PR|https://github.com/apache/velocity-engine/pull/50].
> 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.refledact.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] [Updated] (VELOCITY-952) Velocity is calling the "wrong" method
[
https://issues.apache.org/jira/browse/VELOCITY-952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson updated VELOCITY-952:
Description:
OK, the title is maybe a bit harsh, but it catches the eyes :)
At XWiki we recently started testing on Java 17 to see if there is any problem
which leaded us to add things like {{--add-opens
java.base/java.util=ALL-UNNAMED}} but Velocity happen to be the source of
another problem related to the new module world.
When doing something like {{$datetool.timeZone.getOffset(0)}} ($datetool being
the org.apache.velocity.tools.generic.DateTool) we get the following error:
{noformat}
...
Caused by: java.lang.IllegalAccessException: class
org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl cannot
access class sun.util.calendar.ZoneInfo (in module java.base) because module
java.base does not export sun.util.calendar to unnamed module @7ca16adc
at
java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:392)
at
java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674)
at java.base/java.lang.refledact.Method.invoke(Method.java:560)
at
org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:571)
at
org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:554)
at
org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:221)
... 199 more
{noformat}
The reason is that while the developer intent/expectation was to call
"java.util.TimeZone#getOffset(0)" what Velocity really called from JVM point of
view is "sun.util.calendar.ZoneInfo.getOffset(0)" directly.
That's because Velocity is doing (I assume, since I did not check the exact
code) the equivalent of:
{noformat}
java.util.TimeZone.getDefault().getClass().getMethod("getOffset",
long.class).invoke(TimeZone.getDefault(), 0);
{noformat}
which is itself the equivalent of:
{noformat}
sun.util.calendar.ZoneInfo.class.getMethod("getOffset",
long.class).invoke(TimeZone.getDefault(), 0);
{noformat}
I guess the only way to fix this would be to track down the lowest overridden
Method (I agree, it might not always be easy to choose between two interfaces
declaring a method with the same signature, but choosing the first one we find
from the same hierarchy level is still better than nothing) and call that one
instead. With the use case used as example in this issue, that would mean
ending up doing the equivalent of:
{noformat}
java.util.TimeZone.class.getMethod("getOffset",
long.class).invoke(TimeZone.getDefault(), 0);
{noformat}
which, from JVM point of view, is covered by the {{--add-opens
java.base/java.util=ALL-UNNAMED}}.
It would be a big change, but at least can't think of any retro-compatibility
problem it might cause.
One might be tempted to answer "just add {{--add-opens
java.base/sun.util.calendar=ALL-UNNAMED}}" but it does not seem fair as this is
not what the API that the script uses was exposing at all, you might need to
document a different one for each JVM implementation (even if it's probably
unlikely for this specific example) but more importantly you will potentially
need quite a lot of those and will only discover it at runtime since it's not
so easy to guess from an API in which you only know the public JVM classes
since that's what you manipulate.
I would be happy to work on this, but I wanted first ask what others think
about this problem in general and the possible solutions I may have missed.
was:
OK, the title is maybe a bit harsh, but it catches the eyes :)
At XWiki we recently started testing on Java 17 to see if there is any problem
which leaded us to add things like {{--add-opens
java.base/java.util=ALL-UNNAMED}} but Velocity happen to be the source of
another problem related to the new module world.
When doing something like {{$datetool.timeZone.getOffset(0)}} ($datetool being
the org.apache.velocity.tools.generic.DateTool) we get the following error:
{noformat}
...
Caused by: java.lang.IllegalAccessException: class
org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl cannot
access class sun.util.calendar.ZoneInfo (in module java.base) because module
java.base does not export sun.util.calendar to unnamed module @7ca16adc
at
java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:392)
at
java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674)
at java.base/java.lang.reflect.Method.invoke(Method.java:560)
at
org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:571)
at
org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:554)
at
org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:221)
... 199 more
{noformat}
The reason is that while th
[jira] [Closed] (VELOCITY-979) Performance issue with comparing strings in Velocity
[
https://issues.apache.org/jira/browse/VELOCITY-979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson closed VELOCITY-979.
---
Fix Version/s: 2.4
Resolution: Fixed
Should have been fixed by commit e86a2fbf
> Performance issue with comparing strings in Velocity
>
>
> Key: VELOCITY-979
> URL: https://issues.apache.org/jira/browse/VELOCITY-979
> Project: Velocity
> Issue Type: Improvement
> Components: Engine
>Affects Versions: 2.3
>Reporter: Alex
>Priority: Major
> Fix For: 2.4
>
>
> Most Velocity compare expressions eventually use ASTComparisonNode which at
> first attempts to treat data types as numbers:
>
> Boolean result = compareNumbers(left, right);
> if (result == null)
> {
> result = compareNonNumber(left, right);
> }
>
> There is fairly large overhead when attempting to create BigDecimal from
> non-numeric strings used in comparison in the DuckType.asNumber:
>
> if (coerceType)
> {
> String string = asString(value);// coerce to string
> if (string != null)
> {
> return new BigDecimal(string);
> }
> }
>
> The exception is created capturing stack, etc. On large volume of compare
> operations it's very visible.
>
--
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-957) Unexpected compare result
[
https://issues.apache.org/jira/browse/VELOCITY-957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson closed VELOCITY-957.
---
Fix Version/s: 2.4
Assignee: Claude Brisson
Resolution: Fixed
Fixed by commit e86a2fbf
> 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
>Assignee: Claude Brisson
>Priority: Major
> Fix For: 2.4
>
>
> {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.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Closed] (VELOCITY-944) Macros in string literals are not resolved when local_scope is enabled
[
https://issues.apache.org/jira/browse/VELOCITY-944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson closed VELOCITY-944.
---
Assignee: Claude Brisson
Resolution: Cannot Reproduce
I could not reproduce the problem in any of the 2.x versions. Please reopen
with a complete test case.
> Macros in string literals are not resolved when local_scope is enabled
> --
>
> Key: VELOCITY-944
> URL: https://issues.apache.org/jira/browse/VELOCITY-944
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.0, 2.1, 2.2, 2.3
>Reporter: Jakub Isakow
>Assignee: Claude Brisson
>Priority: Critical
>
> When local scope is enabled with
> {noformat}
> velocimacro.inline.local_scope=true
> {noformat}
> a template that is using a macro in string literal is not working correctly.
> Example template:
> {code}
> #macro( m $v )
> $v
> #end
> #set($v = "#m('bar')")
> $v
> #m( 'foo' )
> {code}
> Actual result:
> {code}
> #m('bar')
> foo
> {code}
> Expected result:
> {code}
> bar
> foo
> {code}
> The example template is working correctly for velocity 1.7.
> After debugging a bit I think the problem might be caused by creating a new
> Template instance in
> [org.apache.velocity.runtime.parser.node.ASTStringLiteral#init|https://github.com/apache/velocity-engine/blob/2.3/velocity-engine-core/src/main/java/org/apache/velocity/runtime/parser/node/ASTStringLiteral.java#L145-L149].
> Because of that, when macro is being resolved, there is no macro instance
> available in local scope (template instance) and it is rendered as string.
> Locally I was able to make it work by using {{this.template}} when
> {{context.getCurrentResource()}} returns {{null}}.
--
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-975) Unicode characters cause issues
[
https://issues.apache.org/jira/browse/VELOCITY-975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson closed VELOCITY-975.
---
Resolution: Incomplete
> Unicode characters cause issues
> ---
>
> Key: VELOCITY-975
> URL: https://issues.apache.org/jira/browse/VELOCITY-975
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Alex O'Ree
>Priority: Major
>
> Ran across some cases of processing files using velocity with some unicode
> characters in it that caused some unexpected results. Is there anything that
> I can do to prevent or mitigate this short of stripping out a set of bad
> characters before i had the script off to velocity?
>
> {noformat}
> org.apache.velocity.exception.ParseErrorException: Lexical error,
> Encountered: "\u00a0" (160), after : "" at *unset*[line 1, column 19]
> at
> org.apache.velocity.runtime.RuntimeInstance.evaluate(RuntimeInstance.java:1437)
> at
> org.apache.velocity.app.VelocityEngine.evaluate(VelocityEngine.java:239)
> {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] [Commented] (VELOCITY-975) Unicode characters cause issues
[
https://issues.apache.org/jira/browse/VELOCITY-975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876494#comment-17876494
]
Claude Brisson commented on VELOCITY-975:
-
The only thing related I could think of is the non-breakable space hack in the
velocity character stream which means "next character is an EOF". But it does
use "\u001C", which does not seem related.
Otherwise, we would need an example of the faulty template section to
understand what's happening.
> Unicode characters cause issues
> ---
>
> Key: VELOCITY-975
> URL: https://issues.apache.org/jira/browse/VELOCITY-975
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Alex O'Ree
>Priority: Major
>
> Ran across some cases of processing files using velocity with some unicode
> characters in it that caused some unexpected results. Is there anything that
> I can do to prevent or mitigate this short of stripping out a set of bad
> characters before i had the script off to velocity?
>
> {noformat}
> org.apache.velocity.exception.ParseErrorException: Lexical error,
> Encountered: "\u00a0" (160), after : "" at *unset*[line 1, column 19]
> at
> org.apache.velocity.runtime.RuntimeInstance.evaluate(RuntimeInstance.java:1437)
> at
> org.apache.velocity.app.VelocityEngine.evaluate(VelocityEngine.java:239)
> {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] [Commented] (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:comment-tabpanel&focusedCommentId=17876469#comment-17876469
]
Claude Brisson commented on VELOCITY-967:
-
Couldn't you use some kind of context chaining?
> Allows passing a list of Template instances to Template#merge
> -
>
> Key: VELOCITY-967
> URL: https://issues.apache.org/jira/browse/VELOCITY-967
> Project: Velocity
> Issue Type: Improvement
> Components: Engine
>Affects Versions: 2.3
>Reporter: Thomas Mortagne
>Priority: Major
>
> Instead of the list of template names.
> In [XWiki|https://www.xwiki.org] it's possible to define Velocity macros in
> all kind of locations (files, pages, attachment in a page, object fields,
> etc.), they can include each other but more importantly you can have 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.
--
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-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
]
Claude Brisson closed VELOCITY-966.
---
Resolution: Invalid
> 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] [Reopened] (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
]
Claude Brisson reopened VELOCITY-966:
-
> 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] [Closed] (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
]
Claude Brisson closed VELOCITY-966.
---
Resolution: Fixed
Since Velocity does support template caching, it does obviously support
rendering several times the same AST.
We would need more details or some example code.
I'm closing the issue for now, but feel free to reopen it if you provide new
materials.
> 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] [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=17876466#comment-17876466
]
Claude Brisson commented on VELOCITY-965:
-
[This PR|https://github.com/apache/velocity-engine/pull/49] fixes thread safety
by means of prepared statements pooling.
> 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] [Closed] (VELOCITY-982) Velocity 2.x - Velocity.properties - Additional introspector.restrict.classes
[ https://issues.apache.org/jira/browse/VELOCITY-982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson closed VELOCITY-982. --- Fix Version/s: 2.4 Assignee: Claude Brisson Resolution: Fixed Requested restrictions have been added by commit 2c15764e > Velocity 2.x - Velocity.properties - Additional introspector.restrict.classes > - > > Key: VELOCITY-982 > URL: https://issues.apache.org/jira/browse/VELOCITY-982 > Project: Velocity > Issue Type: Improvement > Components: Build >Affects Versions: 2.0, 2.1, 2.2, 2.3, 2.4.2 >Reporter: John Tal >Assignee: Claude Brisson >Priority: Major > Fix For: 2.4 > > > In Velocity.properties, the introspector.restrict.classes entries. > I assume additions to this file in that section resolved for CVE-2020-13936 > (templating can interact with the system)? Please confirm what commits or > classes, settings did indeed resolve CVE-2020-13936. We really need to know > because we are stuck on 1.7 and need to fork/patch. > Along these lines of further security hardening, aren't there more entries > needed in the introspect.restrict.classes section such as: > java.lang.ProcessBuilder > java.lang.Reflect > javax.management.MBeanServer > java.net.Socket > javax.script.ScriptEngine > > Finally, please confirm whether Velocity is largely in CVE patch mode only > and is not really an active project given that there is much more talk today > about Apache FreeMarker. Just trying to determine the level of support and > engagement from the Apache Velocity maintainers. -- 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-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:all-tabpanel ] Claude Brisson resolved VELOCITY-969. - Resolution: Duplicate If the performance issue is still here once VELOCITY-979 is fixed, feel free to reopen this issue. > 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 > Attachments: SampleScript.zip > > > 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] [Closed] (VELOCITY-953) VelocimacroProxy polutes context stack due to wrong handling of #break and exceptions
[
https://issues.apache.org/jira/browse/VELOCITY-953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson closed VELOCITY-953.
---
Resolution: Fixed
PR has been merged
> VelocimacroProxy polutes context stack due to wrong handling of #break and
> exceptions
> -
>
> Key: VELOCITY-953
> URL: https://issues.apache.org/jira/browse/VELOCITY-953
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Janek Schumann
>Priority: Major
>
> The render method of org.apache.velocity.runtime.directive.VelocimacroProxy
> contains the following code:
> {code:java}
> try
> {
> // render the velocity macro
> context.pushCurrentMacroName(macroName);
> nodeTree.render(context, writer);
> context.popCurrentMacroName();
> return true;
> }{code}
> Everytime, a VM is exited via #break - or any other exception for that matter
> - the context stack isn't cleaned up properly.
> {{This will lead to a fatal error fast because the max call depth is reached
> quite soon. Even with a max call depth of 200 or more this will happen,
> depending on the complexity of the template and the usage of #break etc.}}
> *{{Proposed solution}}*
> {{Similar to #parse, move the popCurrentMacroName to finally like so}}
> {code:java}
> finally
> {
> // if MacroOverflowException was thrown then it already empties the stack
> // for everything else - e.g. other exceptions - we clean up after ourself
> if (context.getCurrentMacroCallDepth() > 0)
> context.popCurrentMacroName();
> [...]
> }{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-962) Unclosed #[[ is no longer an error
[
https://issues.apache.org/jira/browse/VELOCITY-962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson closed VELOCITY-962.
---
Resolution: Fixed
> 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
> Fix For: 2.4
>
>
> 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] [Commented] (VELOCITY-962) Unclosed #[[ is no longer an error
[
https://issues.apache.org/jira/browse/VELOCITY-962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876416#comment-17876416
]
Claude Brisson commented on VELOCITY-962:
-
Fixed by commit b422860c
> 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
> Fix For: 2.4
>
>
> 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-962) Unclosed #[[ is no longer an error
[
https://issues.apache.org/jira/browse/VELOCITY-962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson updated VELOCITY-962:
Fix Version/s: 2.4
> 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
> Fix For: 2.4
>
>
> 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] (VELTOOLS-210) velocity 1.7 vs velocity 2.3 : the evaluation of if condition in script is different
[
https://issues.apache.org/jira/browse/VELTOOLS-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson updated VELTOOLS-210:
Component/s: VelocityView
> velocity 1.7 vs velocity 2.3 : the evaluation of if condition in script is
> different
> -
>
> Key: VELTOOLS-210
> URL: https://issues.apache.org/jira/browse/VELTOOLS-210
> Project: Velocity Tools
> Issue Type: Bug
> Components: VelocityView
>Affects Versions: 3.1
>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.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Moved] (VELTOOLS-210) velocity 1.7 vs velocity 2.3 : the evaluation of if condition in script is different
[
https://issues.apache.org/jira/browse/VELTOOLS-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson moved VELOCITY-955 to VELTOOLS-210:
--
Key: VELTOOLS-210 (was: VELOCITY-955)
Affects Version/s: 3.1
(was: 2.3)
Project: Velocity Tools (was: Velocity)
> velocity 1.7 vs velocity 2.3 : the evaluation of if condition in script is
> different
> -
>
> Key: VELTOOLS-210
> URL: https://issues.apache.org/jira/browse/VELTOOLS-210
> Project: Velocity Tools
> Issue Type: Bug
>Affects Versions: 3.1
>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.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELTOOLS-209) velocity 1.7 vs velocity 2.3: evaluation of scripts with empty value is not backward compatible
[
https://issues.apache.org/jira/browse/VELTOOLS-209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson updated VELTOOLS-209:
Component/s: GenericTools
> velocity 1.7 vs velocity 2.3: evaluation of scripts with empty value is not
> backward compatible
> ---
>
> Key: VELTOOLS-209
> URL: https://issues.apache.org/jira/browse/VELTOOLS-209
> Project: Velocity Tools
> Issue Type: Bug
> Components: GenericTools
>Affects Versions: 2.0, 3.1
>Reporter: ambika
>Priority: Major
>
> {*}Script{*}:
>
> "vLATE_GATE_IN_6":"#set( $inTimeZone =
> $date.getTimeZone().getTimeZone('Europe/Berlin') )\n\n#set( $outTimeZone =
> $date.getTimeZone().getTimeZone('Asia/Shanghai') )\n\n#set( $locale =
> $date.getLocale() )\n\n#set( $myDate =
> $convert.parseDate(${*}{lead.lateGateIn}{*},\"-MM-dd
> HH:mm\",$locale,$inTimeZone) )\n\n${date.format('-MM-dd hh:mm
> a',$myDate,$locale,$outTimeZone)} "
> {*}note{*}: lead.lateGateIn = "" in the values
> there are multiple other scripts vLATE_GATE_IN_5, vLATE_GATE_IN_4 but in the
> script vLATE_GATE_IN_4 , the values for convert.parseDate is given as below:
> $convert.parseDate("2022-04-22")
>
> {*}Issue{*}:
> Older version of velocity evaluates the script vLATE_GATE_IN_6 to:
> |Time):\\n\\n\\n\\n\\n2022-04-22 11:00 AM|
>
> Newer version of velocity evaluates the script vLATE_GATE_IN_6 to:
> | |Time):\\n\\n\\n\\n\\n${date.format('-MM-dd hh:mm
> a',$myDate,$locale,$outTimeZone)}| |
--
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-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:comment-tabpanel&focusedCommentId=17876414#comment-17876414
]
Claude Brisson commented on VELOCITY-955:
-
You don't give the definition of the getToolscontext() method. I imagine that
you are using velocity-tools, but we need more details.
The issue is probably linked to the
org.apache.velocity.tools.userCanOverwriteTools web integration configuration
parameter, see [tool's related configuration
doc|https://velocity.apache.org/tools/3.1/frameworks.html].
> 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.10#820010)
-
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
]
Claude Brisson updated VELOCITY-955:
Component/s: (was: Scripting)
> 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
>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.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Moved] (VELTOOLS-209) velocity 1.7 vs velocity 2.3: evaluation of scripts with empty value is not backward compatible
[
https://issues.apache.org/jira/browse/VELTOOLS-209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson moved VELOCITY-956 to VELTOOLS-209:
--
Key: VELTOOLS-209 (was: VELOCITY-956)
Affects Version/s: 3.1
2.0
(was: 2.3)
Project: Velocity Tools (was: Velocity)
> velocity 1.7 vs velocity 2.3: evaluation of scripts with empty value is not
> backward compatible
> ---
>
> Key: VELTOOLS-209
> URL: https://issues.apache.org/jira/browse/VELTOOLS-209
> Project: Velocity Tools
> Issue Type: Bug
>Affects Versions: 3.1, 2.0
>Reporter: ambika
>Priority: Major
>
> {*}Script{*}:
>
> "vLATE_GATE_IN_6":"#set( $inTimeZone =
> $date.getTimeZone().getTimeZone('Europe/Berlin') )\n\n#set( $outTimeZone =
> $date.getTimeZone().getTimeZone('Asia/Shanghai') )\n\n#set( $locale =
> $date.getLocale() )\n\n#set( $myDate =
> $convert.parseDate(${*}{lead.lateGateIn}{*},\"-MM-dd
> HH:mm\",$locale,$inTimeZone) )\n\n${date.format('-MM-dd hh:mm
> a',$myDate,$locale,$outTimeZone)} "
> {*}note{*}: lead.lateGateIn = "" in the values
> there are multiple other scripts vLATE_GATE_IN_5, vLATE_GATE_IN_4 but in the
> script vLATE_GATE_IN_4 , the values for convert.parseDate is given as below:
> $convert.parseDate("2022-04-22")
>
> {*}Issue{*}:
> Older version of velocity evaluates the script vLATE_GATE_IN_6 to:
> |Time):\\n\\n\\n\\n\\n2022-04-22 11:00 AM|
>
> Newer version of velocity evaluates the script vLATE_GATE_IN_6 to:
> | |Time):\\n\\n\\n\\n\\n${date.format('-MM-dd hh:mm
> a',$myDate,$locale,$outTimeZone)}| |
--
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-956) velocity 1.7 vs velocity 2.3: evaluation of scripts with empty value is not backward compatible
[
https://issues.apache.org/jira/browse/VELOCITY-956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson updated VELOCITY-956:
Component/s: (was: Engine)
(was: Scripting)
> velocity 1.7 vs velocity 2.3: evaluation of scripts with empty value is not
> backward compatible
> ---
>
> Key: VELOCITY-956
> URL: https://issues.apache.org/jira/browse/VELOCITY-956
> Project: Velocity
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: ambika
>Priority: Major
>
> {*}Script{*}:
>
> "vLATE_GATE_IN_6":"#set( $inTimeZone =
> $date.getTimeZone().getTimeZone('Europe/Berlin') )\n\n#set( $outTimeZone =
> $date.getTimeZone().getTimeZone('Asia/Shanghai') )\n\n#set( $locale =
> $date.getLocale() )\n\n#set( $myDate =
> $convert.parseDate(${*}{lead.lateGateIn}{*},\"-MM-dd
> HH:mm\",$locale,$inTimeZone) )\n\n${date.format('-MM-dd hh:mm
> a',$myDate,$locale,$outTimeZone)} "
> {*}note{*}: lead.lateGateIn = "" in the values
> there are multiple other scripts vLATE_GATE_IN_5, vLATE_GATE_IN_4 but in the
> script vLATE_GATE_IN_4 , the values for convert.parseDate is given as below:
> $convert.parseDate("2022-04-22")
>
> {*}Issue{*}:
> Older version of velocity evaluates the script vLATE_GATE_IN_6 to:
> |Time):\\n\\n\\n\\n\\n2022-04-22 11:00 AM|
>
> Newer version of velocity evaluates the script vLATE_GATE_IN_6 to:
> | |Time):\\n\\n\\n\\n\\n${date.format('-MM-dd hh:mm
> a',$myDate,$locale,$outTimeZone)}| |
--
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-956) velocity 1.7 vs velocity 2.3: evaluation of scripts with empty value is not backward compatible
[
https://issues.apache.org/jira/browse/VELOCITY-956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876411#comment-17876411
]
Claude Brisson commented on VELOCITY-956:
-
I have the following test template:
{code}
#set( $inTimeZone = $date.getTimeZone().getTimeZone('Europe/Berlin') )
#set( $outTimeZone = $date.getTimeZone().getTimeZone('Asia/Shanghai') )
#set( $locale = $date.getLocale() )
#set( $myDate = $convert.parseDate("2022-04-22 00:00","-MM-dd
HH:mm",$locale,$inTimeZone))
inTimeZone = $inTimeZone
outTimeZone = $outTimeZone
locale = $locale
myDate = $myDate
${date.format('-MM-dd hh:mm a',$myDate,$locale,$outTimeZone)}
{code}
I could not exactly reproduce your problem: with engine 2.3 and tools 3.1, as
well with engine 1.7 and tools 2.0, the call $convert.parseDate returns null, I
don't investigate further for now, I'm focusing on the engine issues.
> velocity 1.7 vs velocity 2.3: evaluation of scripts with empty value is not
> backward compatible
> ---
>
> Key: VELOCITY-956
> URL: https://issues.apache.org/jira/browse/VELOCITY-956
> Project: Velocity
> Issue Type: Bug
> Components: Engine, Scripting
>Affects Versions: 2.3
>Reporter: ambika
>Priority: Major
>
> {*}Script{*}:
>
> "vLATE_GATE_IN_6":"#set( $inTimeZone =
> $date.getTimeZone().getTimeZone('Europe/Berlin') )\n\n#set( $outTimeZone =
> $date.getTimeZone().getTimeZone('Asia/Shanghai') )\n\n#set( $locale =
> $date.getLocale() )\n\n#set( $myDate =
> $convert.parseDate(${*}{lead.lateGateIn}{*},\"-MM-dd
> HH:mm\",$locale,$inTimeZone) )\n\n${date.format('-MM-dd hh:mm
> a',$myDate,$locale,$outTimeZone)} "
> {*}note{*}: lead.lateGateIn = "" in the values
> there are multiple other scripts vLATE_GATE_IN_5, vLATE_GATE_IN_4 but in the
> script vLATE_GATE_IN_4 , the values for convert.parseDate is given as below:
> $convert.parseDate("2022-04-22")
>
> {*}Issue{*}:
> Older version of velocity evaluates the script vLATE_GATE_IN_6 to:
> |Time):\\n\\n\\n\\n\\n2022-04-22 11:00 AM|
>
> Newer version of velocity evaluates the script vLATE_GATE_IN_6 to:
> | |Time):\\n\\n\\n\\n\\n${date.format('-MM-dd hh:mm
> a',$myDate,$locale,$outTimeZone)}| |
--
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-962) Unclosed #[[ is no longer an error
[
https://issues.apache.org/jira/browse/VELOCITY-962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876345#comment-17876345
]
Claude Brisson commented on VELOCITY-962:
-
I'm unsure about this one. Hitting the end of the document could implicitly
close the verbatim section.
> 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] [Closed] (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
]
Claude Brisson closed VELOCITY-961.
---
Fix Version/s: 2.4
Resolution: Fixed
Fixed, see [corresponding PR|https://github.com/apache/velocity-engine/pull/47].
> 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
>Assignee: Claude Brisson
>Priority: Minor
> Fix For: 2.4
>
>
> 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] (VELOCITY-961) Parsing regression in Velocity 2.3
[ https://issues.apache.org/jira/browse/VELOCITY-961 ]
Claude Brisson deleted comment on VELOCITY-961:
-
was (Author: claude):
Resolved with the new runtime.immutable_ranges backward
compatibility configuration flag, see [the corresponding
PR|https://github.com/apache/velocity-engine/pull/46]
> 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
>Assignee: Claude Brisson
>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] (VELOCITY-961) Parsing regression in Velocity 2.3
[ https://issues.apache.org/jira/browse/VELOCITY-961 ]
Claude Brisson deleted comment on VELOCITY-961:
-
was (Author: claude):
Ooops, wrong issue
> 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
>Assignee: Claude Brisson
>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] [Closed] (VELOCITY-948) Number ranges created as ASTIntegerRange$IntegerRange in 2.1 rather than java.util.ArrayList
[
https://issues.apache.org/jira/browse/VELOCITY-948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson closed VELOCITY-948.
---
Fix Version/s: 2.4
Resolution: Fixed
Resolved with the new runtime.immutable_ranges backward
compatibility configuration flag, see [the corresponding
PR|https://github.com/apache/velocity-engine/pull/46]
> Number ranges created as ASTIntegerRange$IntegerRange in 2.1 rather than
> java.util.ArrayList
>
>
> Key: VELOCITY-948
> URL: https://issues.apache.org/jira/browse/VELOCITY-948
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.1
>Reporter: Tom White
>Priority: Minor
> Fix For: 2.4
>
>
> Hello!
> I am having issues upgrading from 2.0 to 2.1 with existing templates. The
> minimal below example illustrates the change in behaviour:
> {code:java}
>
>
> #set ($example= [0..50])
> ${example.class.name}
> #set ($example[10] = 500)
>
>
> {code}
>
> With 2.0:
> this prints:
> java.util.ArrayList
> and throws no errors.
>
> With 2.1:
> this prints:
> org.apache.velocity.runtime.parser.node.ASTIntegerRange$IntegerRange
> and throws an UnsupportedMethodException at the set line.
>
> I have tried all kinds of config variables from the docs in a unit test.
> The 2.1 documentation states:
> * The VTL RangeOperator [ 1..10 ] and ObjectArray ["a","b"] are
> {{java.util.ArrayList}} objects when placed in the context or passed to
> methods. Therefore, your methods that are designed to accept arrays created
> in the template should be written with this in mind.
> [https://velocity.apache.org/engine/2.1/developer-guide.html]
>
>
--
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
]
Claude Brisson updated VELOCITY-961:
Fix Version/s: (was: 2.4)
> 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
>Assignee: Claude Brisson
>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] [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
]
Claude Brisson updated VELOCITY-961:
Fix Version/s: 2.4
> 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
>Assignee: Claude Brisson
>Priority: Minor
> Fix For: 2.4
>
>
> 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] [Reopened] (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
]
Claude Brisson reopened VELOCITY-961:
-
Ooops, wrong issue
> 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
>Assignee: Claude Brisson
>Priority: Minor
> Fix For: 2.4
>
>
> 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] [Closed] (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
]
Claude Brisson closed VELOCITY-961.
---
Resolution: Fixed
Resolved with the new runtime.immutable_ranges backward
compatibility configuration flag, see [the corresponding
PR|https://github.com/apache/velocity-engine/pull/46]
> 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] [Assigned] (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
]
Claude Brisson reassigned VELOCITY-961:
---
Assignee: Claude Brisson
> 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
>Assignee: Claude Brisson
>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] [Commented] (VELOCITY-943) File vs. classpath issues with Spring VelocityEngineFactory
[ https://issues.apache.org/jira/browse/VELOCITY-943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876317#comment-17876317 ] Claude Brisson commented on VELOCITY-943: - That would be great! > File vs. classpath issues with Spring VelocityEngineFactory > --- > > Key: VELOCITY-943 > URL: https://issues.apache.org/jira/browse/VELOCITY-943 > Project: Velocity > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Scott Cantor >Priority: Minor > Labels: spring > Attachments: VelocityEngineFactory.java > > > TL;DR, there's a nominal bug fix, and a possible improvement I can suggest, > for the Spring support you copied in from Spring 4 based on the copy we're > using in our project. Our copy differs in some slight ways so a straight > patch diff wasn't very obvious and I'm just going to attach our copy of the > file. > Full explanation: we ported the Spring support into our code for Spring 5 > before you had ported it in, and we were actually prepping a submission for > that but you pulled it in before we had a chance. There were some slight > improvements I made for our use, and today another issue in the same area of > the code got reported and fixed, and it's nominally a bug, so I thought I'd > try submitting that as a possible improvement along with my other change. > The issue is mainly around the way the Spring code combined use of the > File-based Velocity loader with the Spring loader by checking for filesystem > existence on the paths, in order to allow file-based usage to leverage > Velocity's support for template reloading. > In Spring's code (and now your code), there's an issue because it processes > each path via Spring ResourceLoader and then converts the Resource into a > File for an exists() test. If that passes, it installs the file-based loader > instead of the Spring loader. The problem/bug is that some containers unpack > jars, but only partially. Some kind of weird optimization I guess. The result > is that if some of the files get unpacked and not others, this code installs > the file loader and then that fails later because not all the files are there. > The fix seems to be to check for classpath: leading off the path and skip the > exists() check so that it will get deferred to the Spring loader. So that's a > fix, nominally, though right now we've only seen this reported for Wildfly as > a container. > The related enhancement I made was that I allowed for both File-based and > Spring-based paths by walking the complete list and tracking each path set > individually and allowing both loaders to get installed into the Velocity > engine. That was needed for us to support both file-based templates along > with system templates we ship in jars. So as it, we have to have that feature > and can't use the original Spring code, so I'm hoping with the possible > justification of a bug fix, you might take the other change also. > All of the differences that aren't cosmetic are in the > initVelocityResourceLoader method, except that there's also a fix to > initSpringResourceLoader that changes a setProperty to addProperty so that > the Spring loader can get added to the set of loaders and not replace the > file loader. > Apologies that a diff would be so messy but hopefully given that the class is > simple and small, the differences will be clear enough with my explanation. -- 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-943) File vs. classpath issues with Spring VelocityEngineFactory
[ https://issues.apache.org/jira/browse/VELOCITY-943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876199#comment-17876199 ] Claude Brisson commented on VELOCITY-943: - Basically, what you are describing is a change in the default behavior for resources loaders configuration. Instead of tweaking this default one way or another, I think it would be more convenient to let the user explicitly choose the expected behavior, to avoid any surprise. [~scantor] do you think you could help me define a specification for such a configuration that would avoid having to deal with such default behaviors? I am not a spring user myself, so maintaining the Velocity spring module is not easy if no one is stepping in. > File vs. classpath issues with Spring VelocityEngineFactory > --- > > Key: VELOCITY-943 > URL: https://issues.apache.org/jira/browse/VELOCITY-943 > Project: Velocity > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Scott Cantor >Priority: Minor > Labels: spring > Attachments: VelocityEngineFactory.java > > > TL;DR, there's a nominal bug fix, and a possible improvement I can suggest, > for the Spring support you copied in from Spring 4 based on the copy we're > using in our project. Our copy differs in some slight ways so a straight > patch diff wasn't very obvious and I'm just going to attach our copy of the > file. > Full explanation: we ported the Spring support into our code for Spring 5 > before you had ported it in, and we were actually prepping a submission for > that but you pulled it in before we had a chance. There were some slight > improvements I made for our use, and today another issue in the same area of > the code got reported and fixed, and it's nominally a bug, so I thought I'd > try submitting that as a possible improvement along with my other change. > The issue is mainly around the way the Spring code combined use of the > File-based Velocity loader with the Spring loader by checking for filesystem > existence on the paths, in order to allow file-based usage to leverage > Velocity's support for template reloading. > In Spring's code (and now your code), there's an issue because it processes > each path via Spring ResourceLoader and then converts the Resource into a > File for an exists() test. If that passes, it installs the file-based loader > instead of the Spring loader. The problem/bug is that some containers unpack > jars, but only partially. Some kind of weird optimization I guess. The result > is that if some of the files get unpacked and not others, this code installs > the file loader and then that fails later because not all the files are there. > The fix seems to be to check for classpath: leading off the path and skip the > exists() check so that it will get deferred to the Spring loader. So that's a > fix, nominally, though right now we've only seen this reported for Wildfly as > a container. > The related enhancement I made was that I allowed for both File-based and > Spring-based paths by walking the complete list and tracking each path set > individually and allowing both loaders to get installed into the Velocity > engine. That was needed for us to support both file-based templates along > with system templates we ship in jars. So as it, we have to have that feature > and can't use the original Spring code, so I'm hoping with the possible > justification of a bug fix, you might take the other change also. > All of the differences that aren't cosmetic are in the > initVelocityResourceLoader method, except that there's also a fix to > initSpringResourceLoader that changes a setProperty to addProperty so that > the Spring loader can get added to the set of loaders and not replace the > file loader. > Apologies that a diff would be so messy but hopefully given that the class is > simple and small, the differences will be clear enough with my explanation. -- 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-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=17876190#comment-17876190 ] Claude Brisson commented on VELOCITY-969: - We need more profiling information or a reproducible example to be able to fix such issues. I'm going to address VELOCITY-979 in the next release, as this one is well identified, maybe it will fix the performance problems you are experiencing. > 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 > Attachments: SampleScript.zip > > > 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] (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:comment-tabpanel&focusedCommentId=17867041#comment-17867041 ] Claude Brisson commented on VELTOOLS-202: - A classifier is a way to go, IMO. > 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] (VELTOOLS-206) Upgrade to Velocity Engine 2.4.2
[ https://issues.apache.org/jira/browse/VELTOOLS-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17823138#comment-17823138 ] Claude Brisson commented on VELTOOLS-206: - 2.4.2 ?! So you're not comming back to 2.4? I don't understand why. Even if a tag is public, you can delete it. > Upgrade to Velocity Engine 2.4.2 > > > Key: VELTOOLS-206 > URL: https://issues.apache.org/jira/browse/VELTOOLS-206 > Project: Velocity Tools > Issue Type: Task >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 3.2.1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-970) velocity-engine-core contains commons-io Maven descriptor
[ https://issues.apache.org/jira/browse/VELOCITY-970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17805706#comment-17805706 ] Claude Brisson commented on VELOCITY-970: - That's not strange, that's an effect of the shading: one pom is to compile it, one to use it at runtime. > velocity-engine-core contains commons-io Maven descriptor > - > > Key: VELOCITY-970 > URL: https://issues.apache.org/jira/browse/VELOCITY-970 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.3 >Reporter: Thomas Mortagne >Priority: Major > > commons-io is embedded in velocity-engine-core, which is OK from Java point > of view since its package is renamed (not causing any dependency problems). > The problem is that it contains the commons-io Maven descriptors at the > standard location (/META-INF/maven/commons-io/commons-io/), which is a > problem when you analyze JAR files to find what's in it because it ends up > being identified as a JAR exposing commons-io (which is not the case since > it's weaved). > Honestly, it feels very strange to embed commons-io in the first place given > that commons-lang for example is a transitive dependency, so I feel like the > simplest would just be to remove all the plumbing to embed and weave > commons-io and simply keep it as a regular transitive dependency. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-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] [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=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-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] [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] [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] [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] [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] [Resolved] (VELTOOLS-192) EasyFactoryConfiguration.addDefaultTools() method overwrite previously added tools
[ https://issues.apache.org/jira/browse/VELTOOLS-192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson resolved VELTOOLS-192. - Fix Version/s: 3.2 Resolution: Fixed Fixed by commit 994c555d. > EasyFactoryConfiguration.addDefaultTools() method overwrite previously added > tools > -- > > Key: VELTOOLS-192 > URL: https://issues.apache.org/jira/browse/VELTOOLS-192 > Project: Velocity Tools > Issue Type: Bug > Components: GenericTools >Affects Versions: 3.1 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Major > Fix For: 3.2 > > > The EasyFactoryConfiguration.addDefaultTools() method will overwrite all > custom tools previously added (for instance with the tools(...) method). -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Resolved] (VELTOOLS-193) XmlTool not accepting comments
[ https://issues.apache.org/jira/browse/VELTOOLS-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson resolved VELTOOLS-193. - Fix Version/s: 3.2 Resolution: Fixed Fixed by commit d5ecd327 > XmlTool not accepting comments > -- > > Key: VELTOOLS-193 > URL: https://issues.apache.org/jira/browse/VELTOOLS-193 > Project: Velocity Tools > Issue Type: Bug > Components: GenericTools >Affects Versions: 3.1 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Major > Fix For: 3.2 > > > XML documents or fragments containing XML comments cannot be parsed by > XmlTool. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELTOOLS-194) XmlTool getName()/getNodeName() logic should be the same for getPath()/getNodePath()
[
https://issues.apache.org/jira/browse/VELTOOLS-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17464258#comment-17464258
]
Claude Brisson commented on VELTOOLS-194:
-
First step (deprecation of getPath()) pushed to master, see 7c182b10.
> XmlTool getName()/getNodeName() logic should be the same for
> getPath()/getNodePath()
>
>
> Key: VELTOOLS-194
> URL: https://issues.apache.org/jira/browse/VELTOOLS-194
> Project: Velocity Tools
> Issue Type: Bug
> Components: GenericTools
>Affects Versions: 3.1
>Reporter: Claude Brisson
>Assignee: Claude Brisson
>Priority: Minor
>
> In XmlTool, the method getName() first checks get("name") before calling
> getNodeName().
> The "path" property should follow the same logic. getPath() should be
> deprecated in favor of getNodePath() so that the new behavior is valid in the
> next major release.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Created] (VELTOOLS-194) XmlTool getName()/getNodeName() logic should be the same for getPath()/getNodePath()
Claude Brisson created VELTOOLS-194:
---
Summary: XmlTool getName()/getNodeName() logic should be the same
for getPath()/getNodePath()
Key: VELTOOLS-194
URL: https://issues.apache.org/jira/browse/VELTOOLS-194
Project: Velocity Tools
Issue Type: Bug
Components: GenericTools
Affects Versions: 3.1
Reporter: Claude Brisson
Assignee: Claude Brisson
In XmlTool, the method getName() first checks get("name") before calling
getNodeName().
The "path" property should follow the same logic. getPath() should be
deprecated in favor of getNodePath() so that the new behavior is valid in the
next major release.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Created] (VELTOOLS-193) XmlTool not accepting comments
Claude Brisson created VELTOOLS-193: --- Summary: XmlTool not accepting comments Key: VELTOOLS-193 URL: https://issues.apache.org/jira/browse/VELTOOLS-193 Project: Velocity Tools Issue Type: Bug Components: GenericTools Affects Versions: 3.1 Reporter: Claude Brisson Assignee: Claude Brisson XML documents or fragments containing XML comments cannot be parsed by XmlTool. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Closed] (VELTOOLS-187) Upgrading to beanutils 1.9.4 breaks tools "class" attribute
[ https://issues.apache.org/jira/browse/VELTOOLS-187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson closed VELTOOLS-187. --- > Upgrading to beanutils 1.9.4 breaks tools "class" attribute > --- > > Key: VELTOOLS-187 > URL: https://issues.apache.org/jira/browse/VELTOOLS-187 > Project: Velocity Tools > Issue Type: Bug > Components: GenericTools, VelocityView >Affects Versions: 3.0 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Major > Fix For: 3.1 > > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Closed] (VELTOOLS-185) Upgrade Codehaus Cargo version
[ https://issues.apache.org/jira/browse/VELTOOLS-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson closed VELTOOLS-185. --- > Upgrade Codehaus Cargo version > -- > > Key: VELTOOLS-185 > URL: https://issues.apache.org/jira/browse/VELTOOLS-185 > Project: Velocity Tools > Issue Type: Improvement >Reporter: S. Ali Tokmen >Assignee: Claude Brisson >Priority: Minor > Fix For: 3.1 > > Attachments: update-codehaus-cargo-version.patch > > > Codehaus Cargo has, since the version currently in use in the Velocity tools, > accumulated many interesting fixes and improvements, moreover had important > adaptations as [Maven and many other repositories switched to HTTPS-only > since mid January > 2020|https://www.alphabot.com/security/blog/2020/java/Your-Java-builds-might-break-starting-January-13th.html]. > Attached is a patch to upgrade to the latest version. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Created] (VELTOOLS-192) EasyFactoryConfiguration.addDefaultTools() method overwrite previously added tools
Claude Brisson created VELTOOLS-192: --- Summary: EasyFactoryConfiguration.addDefaultTools() method overwrite previously added tools Key: VELTOOLS-192 URL: https://issues.apache.org/jira/browse/VELTOOLS-192 Project: Velocity Tools Issue Type: Bug Components: GenericTools Affects Versions: 3.1 Reporter: Claude Brisson Assignee: Claude Brisson The EasyFactoryConfiguration.addDefaultTools() method will overwrite all custom tools previously added (for instance with the tools(...) method). -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-948) Number ranges created as ASTIntegerRange$IntegerRange in 2.1 rather than java.util.ArrayList
[
https://issues.apache.org/jira/browse/VELOCITY-948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17417332#comment-17417332
]
Claude Brisson commented on VELOCITY-948:
-
We could add an immutable `IntegerRange.toList()` method for such use cases.
> Number ranges created as ASTIntegerRange$IntegerRange in 2.1 rather than
> java.util.ArrayList
>
>
> Key: VELOCITY-948
> URL: https://issues.apache.org/jira/browse/VELOCITY-948
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.1
>Reporter: Tom White
>Priority: Minor
>
> Hello!
> I am having issues upgrading from 2.0 to 2.1 with existing templates. The
> minimal below example illustrates the change in behaviour:
> {code:java}
>
>
> #set ($example= [0..50])
> ${example.class.name}
> #set ($example[10] = 500)
>
>
> {code}
>
> With 2.0:
> this prints:
> java.util.ArrayList
> and throws no errors.
>
> With 2.1:
> this prints:
> org.apache.velocity.runtime.parser.node.ASTIntegerRange$IntegerRange
> and throws an UnsupportedMethodException at the set line.
>
> I have tried all kinds of config variables from the docs in a unit test.
> The 2.1 documentation states:
> * The VTL RangeOperator [ 1..10 ] and ObjectArray ["a","b"] are
> {{java.util.ArrayList}} objects when placed in the context or passed to
> methods. Therefore, your methods that are designed to accept arrays created
> in the template should be written with this in mind.
> [https://velocity.apache.org/engine/2.1/developer-guide.html]
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-948) Number ranges created as ASTIntegerRange$IntegerRange in 2.1 rather than java.util.ArrayList
[
https://issues.apache.org/jira/browse/VELOCITY-948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17413489#comment-17413489
]
Claude Brisson commented on VELOCITY-948:
-
I think it's the doc which should be updated, rather than the code. The change
comes from [VELOCITY-886|https://issues.apache.org/jira/browse/VELOCITY-886].
Updating values inside a range seems a rather exotic use case, no?
> Number ranges created as ASTIntegerRange$IntegerRange in 2.1 rather than
> java.util.ArrayList
>
>
> Key: VELOCITY-948
> URL: https://issues.apache.org/jira/browse/VELOCITY-948
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.1
>Reporter: Tom White
>Priority: Minor
>
> Hello!
> I am having issues upgrading from 2.0 to 2.1 with existing templates. The
> minimal below example illustrates the change in behaviour:
> {code:java}
>
>
> #set ($example= [0..50])
> ${example.class.name}
> #set ($example[10] = 500)
>
>
> {code}
>
> With 2.0:
> this prints:
> java.util.ArrayList
> and throws no errors.
>
> With 2.1:
> this prints:
> org.apache.velocity.runtime.parser.node.ASTIntegerRange$IntegerRange
> and throws an UnsupportedMethodException at the set line.
>
> I have tried all kinds of config variables from the docs in a unit test.
> The 2.1 documentation states:
> * The VTL RangeOperator [ 1..10 ] and ObjectArray ["a","b"] are
> {{java.util.ArrayList}} objects when placed in the context or passed to
> methods. Therefore, your methods that are designed to accept arrays created
> in the template should be written with this in mind.
> [https://velocity.apache.org/engine/2.1/developer-guide.html]
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Resolved] (VELOCITY-939) Download page must mention verification
[ https://issues.apache.org/jira/browse/VELOCITY-939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson resolved VELOCITY-939. - Assignee: Claude Brisson Resolution: Fixed "Verifying integrity" section added. Thanks for the report. > Download page must mention verification > --- > > Key: VELOCITY-939 > URL: https://issues.apache.org/jira/browse/VELOCITY-939 > Project: Velocity > Issue Type: Bug >Reporter: Sebb >Assignee: Claude Brisson >Priority: Major > > Download pages must mention the need to verify downloaded artifacts and > describe how to do so using KEYS and/or hashes -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Closed] (VELOCITY-939) Download page must mention verification
[ https://issues.apache.org/jira/browse/VELOCITY-939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson closed VELOCITY-939. --- > Download page must mention verification > --- > > Key: VELOCITY-939 > URL: https://issues.apache.org/jira/browse/VELOCITY-939 > Project: Velocity > Issue Type: Bug >Reporter: Sebb >Assignee: Claude Brisson >Priority: Major > > Download pages must mention the need to verify downloaded artifacts and > describe how to do so using KEYS and/or hashes -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
