[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=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=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=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=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=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=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=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=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=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=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=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=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=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
[jira] [Closed] (VELOCITY-938) Broken links for spring-velocity-support
[ https://issues.apache.org/jira/browse/VELOCITY-938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson closed VELOCITY-938. --- Assignee: Claude Brisson > Broken links for spring-velocity-support > > > Key: VELOCITY-938 > URL: https://issues.apache.org/jira/browse/VELOCITY-938 > Project: Velocity > Issue Type: Bug >Reporter: Sebb >Assignee: Claude Brisson >Priority: Major > > The links for spring-velocity-support are broken - looks like wrong file names -- 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-938) Broken links for spring-velocity-support
[ https://issues.apache.org/jira/browse/VELOCITY-938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson resolved VELOCITY-938. - Resolution: Fixed Thanks, fixed. > Broken links for spring-velocity-support > > > Key: VELOCITY-938 > URL: https://issues.apache.org/jira/browse/VELOCITY-938 > Project: Velocity > Issue Type: Bug >Reporter: Sebb >Priority: Major > > The links for spring-velocity-support are broken - looks like wrong file names -- 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-936) Download page issues
[ https://issues.apache.org/jira/browse/VELOCITY-936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson resolved VELOCITY-936. - Resolution: Fixed Snaphot releases removed, archives linked to the archive server. > Download page issues > > > Key: VELOCITY-936 > URL: https://issues.apache.org/jira/browse/VELOCITY-936 > Project: Velocity > Issue Type: Bug > Environment: https://velocity.apache.org/download.cgi >Reporter: Sebb >Priority: Major > > The download page has some issues. > Snapshot releases are only intended for developers, and must not be published > on pages intended for the general public [1] > Also there are references to archived releases [2]. These should be linked > from the archive server ([https://archive.apache.org/dist/velocity/),] and > the files removed from the mirrors. > It's unfair to expect the volunteer mirrors to carry archived versions. > [1] [https://www.apache.org/legal/release-policy.html#publication] > [2] https://velocity.apache.org/download.cgi#archived-components-releases > > > -- 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-936) Download page issues
[ https://issues.apache.org/jira/browse/VELOCITY-936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson closed VELOCITY-936. --- > Download page issues > > > Key: VELOCITY-936 > URL: https://issues.apache.org/jira/browse/VELOCITY-936 > Project: Velocity > Issue Type: Bug > Environment: https://velocity.apache.org/download.cgi >Reporter: Sebb >Assignee: Claude Brisson >Priority: Major > > The download page has some issues. > Snapshot releases are only intended for developers, and must not be published > on pages intended for the general public [1] > Also there are references to archived releases [2]. These should be linked > from the archive server ([https://archive.apache.org/dist/velocity/),] and > the files removed from the mirrors. > It's unfair to expect the volunteer mirrors to carry archived versions. > [1] [https://www.apache.org/legal/release-policy.html#publication] > [2] https://velocity.apache.org/download.cgi#archived-components-releases > > > -- 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-907) Moderators needed for general list
[ https://issues.apache.org/jira/browse/VELOCITY-907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17292864#comment-17292864 ] Claude Brisson commented on VELOCITY-907: - Yes, of course, I don't see why not, since you're already a PMC in several other Apache projects. > Moderators needed for general list > -- > > Key: VELOCITY-907 > URL: https://issues.apache.org/jira/browse/VELOCITY-907 > Project: Velocity > Issue Type: Bug >Reporter: Sebb >Priority: Major > > There are currently no moderators for the -commits@- or general@ lists [1] > Some volunteers need to step up. > In the meantime I have added myself, but that can only be temporary. > [1] > [https://whimsy.apache.org/roster/committee/velocity#mail|https://whimsy.apache.org/roster/committee/santuario#mail] -- 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] (VELTOOLS-182) MathTool.max longtime bug with args (0,0)
[
https://issues.apache.org/jira/browse/VELTOOLS-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson closed VELTOOLS-182.
---
> MathTool.max longtime bug with args (0,0)
> -
>
> Key: VELTOOLS-182
> URL: https://issues.apache.org/jira/browse/VELTOOLS-182
> Project: Velocity Tools
> Issue Type: Bug
> Components: GenericTools
>Affects Versions: 2.0
>Reporter: Sanford Whiteman
>Assignee: Claude Brisson
>Priority: Major
> Fix For: 3.1
>
>
> It appears that {{$math.max}} has had a bug since at least 2.0, or at least
> I'm at a loss as to why the observed behavior would be expected, and it
> doesn't appear to be documented.
>
> {code:java}
> $math.max(0,0) {code}
>
> returns
>
> {code:java}
> 4.9E-324{code}
>
> that is, Double.MIN_VALUE.
>
> It's easy to see why in the source. Using
> [3.0|https://apache.googlesource.com/velocity-tools/+/trunk/velocity-tools-generic/src/main/java/org/apache/velocity/tools/generic/MathTool.java#377]
> here, we see:
>
> {code:java}
> public Number max(Object... nums)
> {
> double value = Double.MIN_VALUE;
> Number[] ns = new Number[nums.length];
> for (int i=0; i {
> Number n = toNumber(nums[i]);
> if (n == null)
> {
> return null;
> }
> value = Math.max(value, n.doubleValue());
> ns[i] = n;
> }
> return matchType(value, ns);
> }
> {code}
>
> So rather than delegating to {{Java.lang.Math.max}} directly, each iter takes
> the {{Math.max}} of the current value and Double.MIN_VALUE. Ergo, if the
> arguments are 0, that's always < Double.MIN_VALUE, so the result is in turn
> Double.MIN_VALUE.
> The same goes for {{$math.max(0)}} (just one arg) but at least that could be
> considered a usage error.
--
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] (VELTOOLS-182) MathTool.max longtime bug with args (0,0)
[
https://issues.apache.org/jira/browse/VELTOOLS-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson resolved VELTOOLS-182.
-
Fix Version/s: 3.1
Assignee: Claude Brisson
Resolution: Fixed
Fixed
> MathTool.max longtime bug with args (0,0)
> -
>
> Key: VELTOOLS-182
> URL: https://issues.apache.org/jira/browse/VELTOOLS-182
> Project: Velocity Tools
> Issue Type: Bug
> Components: GenericTools
>Affects Versions: 2.0
>Reporter: Sanford Whiteman
>Assignee: Claude Brisson
>Priority: Major
> Fix For: 3.1
>
>
> It appears that {{$math.max}} has had a bug since at least 2.0, or at least
> I'm at a loss as to why the observed behavior would be expected, and it
> doesn't appear to be documented.
>
> {code:java}
> $math.max(0,0) {code}
>
> returns
>
> {code:java}
> 4.9E-324{code}
>
> that is, Double.MIN_VALUE.
>
> It's easy to see why in the source. Using
> [3.0|https://apache.googlesource.com/velocity-tools/+/trunk/velocity-tools-generic/src/main/java/org/apache/velocity/tools/generic/MathTool.java#377]
> here, we see:
>
> {code:java}
> public Number max(Object... nums)
> {
> double value = Double.MIN_VALUE;
> Number[] ns = new Number[nums.length];
> for (int i=0; i {
> Number n = toNumber(nums[i]);
> if (n == null)
> {
> return null;
> }
> value = Math.max(value, n.doubleValue());
> ns[i] = n;
> }
> return matchType(value, ns);
> }
> {code}
>
> So rather than delegating to {{Java.lang.Math.max}} directly, each iter takes
> the {{Math.max}} of the current value and Double.MIN_VALUE. Ergo, if the
> arguments are 0, that's always < Double.MIN_VALUE, so the result is in turn
> Double.MIN_VALUE.
> The same goes for {{$math.max(0)}} (just one arg) but at least that could be
> considered a usage error.
--
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-933) Spring support for Velocity
[ https://issues.apache.org/jira/browse/VELOCITY-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17292097#comment-17292097 ] Claude Brisson commented on VELOCITY-933: - [~timcolson] Found and fixed, thanks. > Spring support for Velocity > --- > > Key: VELOCITY-933 > URL: https://issues.apache.org/jira/browse/VELOCITY-933 > Project: Velocity > Issue Type: Task > Components: Engine >Affects Versions: 2.3 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Major > Fix For: 2.3 > > Attachments: 2021-02-12 Vel 2.2 shows 1.7.png, Velocity Search > Results.png, image-2021-02-12-12-13-04-901.png > > > Add a new jar submodule for Velocity Spring support -- 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-933) Spring support for Velocity
[ https://issues.apache.org/jira/browse/VELOCITY-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson resolved VELOCITY-933. - Resolution: Fixed Merged to master. > Spring support for Velocity > --- > > Key: VELOCITY-933 > URL: https://issues.apache.org/jira/browse/VELOCITY-933 > Project: Velocity > Issue Type: Task > Components: Engine >Affects Versions: 2.3 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Major > Fix For: 2.3 > > Attachments: 2021-02-12 Vel 2.2 shows 1.7.png, Velocity Search > Results.png, image-2021-02-12-12-13-04-901.png > > > Add a new jar submodule for Velocity Spring support -- 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-931) SecureUberspector should block methods on ClassLoader and subclasses
[ https://issues.apache.org/jira/browse/VELOCITY-931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17292096#comment-17292096 ] Claude Brisson commented on VELOCITY-931: - Ok, found and fixed. > SecureUberspector should block methods on ClassLoader and subclasses > > > Key: VELOCITY-931 > URL: https://issues.apache.org/jira/browse/VELOCITY-931 > Project: Velocity > Issue Type: Improvement >Reporter: William Glass-Husain >Assignee: William Glass-Husain >Priority: Major > Fix For: 2.3 > > > Currently, SecureUberspector matches classes stored with property > "introspector.restrict.classes", which includes ClassLoader. It then > matches exact class names and blocks all methods from being called on that > class. > However, in most cases it's actually a subclass of ClassLoader that's > available in the context, which under normal circumstances would not be > blocked. > My proposal – treat this as a special case. (Remove it from the > configuration). If the class being inspected is assignable from ClassLoader, > then block it. > You could make an argument that all the SecureUberspector should check if the > class isAssignable from all configured classes, but I am concerned about > possible performance penalties. I'd argue that we should hard code checks > for a few special internal classes but force the user to configure other > specific classes themselves. > -- 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] [Issue Comment Deleted] (VELOCITY-931) SecureUberspector should block methods on ClassLoader and subclasses
[ https://issues.apache.org/jira/browse/VELOCITY-931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson updated VELOCITY-931: Comment: was deleted (was: Ok, found and fixed.) > SecureUberspector should block methods on ClassLoader and subclasses > > > Key: VELOCITY-931 > URL: https://issues.apache.org/jira/browse/VELOCITY-931 > Project: Velocity > Issue Type: Improvement >Reporter: William Glass-Husain >Assignee: William Glass-Husain >Priority: Major > Fix For: 2.3 > > > Currently, SecureUberspector matches classes stored with property > "introspector.restrict.classes", which includes ClassLoader. It then > matches exact class names and blocks all methods from being called on that > class. > However, in most cases it's actually a subclass of ClassLoader that's > available in the context, which under normal circumstances would not be > blocked. > My proposal – treat this as a special case. (Remove it from the > configuration). If the class being inspected is assignable from ClassLoader, > then block it. > You could make an argument that all the SecureUberspector should check if the > class isAssignable from all configured classes, but I am concerned about > possible performance penalties. I'd argue that we should hard code checks > for a few special internal classes but force the user to configure other > specific classes themselves. > -- 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-932) Resource not found when executing jar file, works fine in IDE
[
https://issues.apache.org/jira/browse/VELOCITY-932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson closed VELOCITY-932.
---
Assignee: Claude Brisson
> Resource not found when executing jar file, works fine in IDE
> -
>
> Key: VELOCITY-932
> URL: https://issues.apache.org/jira/browse/VELOCITY-932
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 1.7.x, 2.2
> Environment: local
>Reporter: ecstasy
>Assignee: Claude Brisson
>Priority: Major
> Attachments: TestVelocity_src.zip
>
>
> Hello, I have a simple maven project with 1 class file. The project works
> fine in eclipse but when creating a jar out of it and executing it, it runs
> into error of ResourceNotFound
>
> {code:java}
> SEVERE: ResourceManager : unable to find resource
> '\templates\welcomeLetter.vm' in any resource loader.
> Exception in thread "main" java.lang.ExceptionInInitializerError
> Caused by: org.apache.velocity.exception.ResourceNotFoundException: Unable to
> find resource '\templates\welcomeLetter.vm'
> at
> org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:474)
> at
> org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:352)
> at
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1533)
> at
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1514)
> at
> org.apache.velocity.app.VelocityEngine.getTemplate(VelocityEngine.java:373)
> at
> net.rajanpanchal.handlers.WelcomeLetterGeneratorHandler.(WelcomeLetterGeneratorHandler.java:48)
> {code}
>
> Class file:
> {code:java}
> public class WelcomeLetterGeneratorHandler implements
> RequestHandler, String> {
> String fileObjKeyName = "welcome_letter.txt";
> static VelocityContext vContext;
> static Template t;
>
> static {
> // Create a new Velocity Engine
> VelocityEngine velocityEngine = new VelocityEngine();
> // Set properties that allow reading vm file from classpath.
> Properties p = new Properties();
> velocityEngine.setProperty(RuntimeConstants.RESOURCE_LOADER,
> "file,class,classpath");
> velocityEngine.setProperty("class.resource.loader.class",
>
> "org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader");
> velocityEngine.setProperty("file.resource.loader.path",
> "classpath");
> try {
> velocityEngine.init(p);
> } catch (Exception e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
> // read the template from resources folder
> System.out.println("Current
> dir:"+System.getProperty("user.dir"));
> try {
> t =
> velocityEngine.getTemplate("\\templates\\welcomeLetter.vm");
> } catch (ResourceNotFoundException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> } catch (ParseErrorException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> } catch (Exception e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> } vContext = new VelocityContext();
> } public String handleRequest(Map event, Context
> context) {
> String response = new String("200 OK");
> try {
> // Add data to velocity context
> vContext.put("name", "Joe");
> File f = new File(fileObjKeyName);
> FileWriter writer = new FileWriter(f);
> // merge template and Data
> t.merge(vContext, writer);
> writer.flush();
> writer.close(); } catch (Exception ex) {
> throw new RuntimeException(ex);
> } return response;
> }
>
> public static void main(String[] args) {
> // TODO Auto-generated method stub
> WelcomeLetterGeneratorHandler handler = new
> WelcomeLetterGeneratorHandler();
> Context context = null;
> handler.handleRequest(null, context);
>
> /* first, we init the runtime engine. Defaults are fine. */
> }
> }
> {code}
> Attaching Source maven project.
[jira] [Resolved] (VELOCITY-932) Resource not found when executing jar file, works fine in IDE
[
https://issues.apache.org/jira/browse/VELOCITY-932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson resolved VELOCITY-932.
-
Resolution: Not A Bug
> Resource not found when executing jar file, works fine in IDE
> -
>
> Key: VELOCITY-932
> URL: https://issues.apache.org/jira/browse/VELOCITY-932
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 1.7.x, 2.2
> Environment: local
>Reporter: ecstasy
>Priority: Major
> Attachments: TestVelocity_src.zip
>
>
> Hello, I have a simple maven project with 1 class file. The project works
> fine in eclipse but when creating a jar out of it and executing it, it runs
> into error of ResourceNotFound
>
> {code:java}
> SEVERE: ResourceManager : unable to find resource
> '\templates\welcomeLetter.vm' in any resource loader.
> Exception in thread "main" java.lang.ExceptionInInitializerError
> Caused by: org.apache.velocity.exception.ResourceNotFoundException: Unable to
> find resource '\templates\welcomeLetter.vm'
> at
> org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:474)
> at
> org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:352)
> at
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1533)
> at
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1514)
> at
> org.apache.velocity.app.VelocityEngine.getTemplate(VelocityEngine.java:373)
> at
> net.rajanpanchal.handlers.WelcomeLetterGeneratorHandler.(WelcomeLetterGeneratorHandler.java:48)
> {code}
>
> Class file:
> {code:java}
> public class WelcomeLetterGeneratorHandler implements
> RequestHandler, String> {
> String fileObjKeyName = "welcome_letter.txt";
> static VelocityContext vContext;
> static Template t;
>
> static {
> // Create a new Velocity Engine
> VelocityEngine velocityEngine = new VelocityEngine();
> // Set properties that allow reading vm file from classpath.
> Properties p = new Properties();
> velocityEngine.setProperty(RuntimeConstants.RESOURCE_LOADER,
> "file,class,classpath");
> velocityEngine.setProperty("class.resource.loader.class",
>
> "org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader");
> velocityEngine.setProperty("file.resource.loader.path",
> "classpath");
> try {
> velocityEngine.init(p);
> } catch (Exception e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
> // read the template from resources folder
> System.out.println("Current
> dir:"+System.getProperty("user.dir"));
> try {
> t =
> velocityEngine.getTemplate("\\templates\\welcomeLetter.vm");
> } catch (ResourceNotFoundException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> } catch (ParseErrorException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> } catch (Exception e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> } vContext = new VelocityContext();
> } public String handleRequest(Map event, Context
> context) {
> String response = new String("200 OK");
> try {
> // Add data to velocity context
> vContext.put("name", "Joe");
> File f = new File(fileObjKeyName);
> FileWriter writer = new FileWriter(f);
> // merge template and Data
> t.merge(vContext, writer);
> writer.flush();
> writer.close(); } catch (Exception ex) {
> throw new RuntimeException(ex);
> } return response;
> }
>
> public static void main(String[] args) {
> // TODO Auto-generated method stub
> WelcomeLetterGeneratorHandler handler = new
> WelcomeLetterGeneratorHandler();
> Context context = null;
> handler.handleRequest(null, context);
>
> /* first, we init the runtime engine. Defaults are fine. */
> }
> }
> {code}
> Attaching Source maven project.
--
This message was sent by Atlassian
[jira] [Commented] (VELOCITY-932) Resource not found when executing jar file, works fine in IDE
[
https://issues.apache.org/jira/browse/VELOCITY-932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17292058#comment-17292058
]
Claude Brisson commented on VELOCITY-932:
-
[~ecstasy] I don't know what you mean by this line:
{code:java}
velocityEngine.setProperty("file.resource.loader.path", "classpath");
{code}
Obviously, you would need to give a real path to this property, something like:
{code:java}
velocityEngine.setProperty("file.resource.loader.path",
System.getProperty("user.dir"));
{code}
> Resource not found when executing jar file, works fine in IDE
> -
>
> Key: VELOCITY-932
> URL: https://issues.apache.org/jira/browse/VELOCITY-932
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 1.7.x, 2.2
> Environment: local
>Reporter: ecstasy
>Priority: Major
> Attachments: TestVelocity_src.zip
>
>
> Hello, I have a simple maven project with 1 class file. The project works
> fine in eclipse but when creating a jar out of it and executing it, it runs
> into error of ResourceNotFound
>
> {code:java}
> SEVERE: ResourceManager : unable to find resource
> '\templates\welcomeLetter.vm' in any resource loader.
> Exception in thread "main" java.lang.ExceptionInInitializerError
> Caused by: org.apache.velocity.exception.ResourceNotFoundException: Unable to
> find resource '\templates\welcomeLetter.vm'
> at
> org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:474)
> at
> org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:352)
> at
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1533)
> at
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1514)
> at
> org.apache.velocity.app.VelocityEngine.getTemplate(VelocityEngine.java:373)
> at
> net.rajanpanchal.handlers.WelcomeLetterGeneratorHandler.(WelcomeLetterGeneratorHandler.java:48)
> {code}
>
> Class file:
> {code:java}
> public class WelcomeLetterGeneratorHandler implements
> RequestHandler, String> {
> String fileObjKeyName = "welcome_letter.txt";
> static VelocityContext vContext;
> static Template t;
>
> static {
> // Create a new Velocity Engine
> VelocityEngine velocityEngine = new VelocityEngine();
> // Set properties that allow reading vm file from classpath.
> Properties p = new Properties();
> velocityEngine.setProperty(RuntimeConstants.RESOURCE_LOADER,
> "file,class,classpath");
> velocityEngine.setProperty("class.resource.loader.class",
>
> "org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader");
> velocityEngine.setProperty("file.resource.loader.path",
> "classpath");
> try {
> velocityEngine.init(p);
> } catch (Exception e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
> // read the template from resources folder
> System.out.println("Current
> dir:"+System.getProperty("user.dir"));
> try {
> t =
> velocityEngine.getTemplate("\\templates\\welcomeLetter.vm");
> } catch (ResourceNotFoundException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> } catch (ParseErrorException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> } catch (Exception e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> } vContext = new VelocityContext();
> } public String handleRequest(Map event, Context
> context) {
> String response = new String("200 OK");
> try {
> // Add data to velocity context
> vContext.put("name", "Joe");
> File f = new File(fileObjKeyName);
> FileWriter writer = new FileWriter(f);
> // merge template and Data
> t.merge(vContext, writer);
> writer.flush();
> writer.close(); } catch (Exception ex) {
> throw new RuntimeException(ex);
> } return response;
> }
>
> public static void main(String[] args) {
> // TODO Auto-generated method stub
>
[jira] [Resolved] (VELOCITY-927) Parsing problem with space before closing curly bracket
[
https://issues.apache.org/jira/browse/VELOCITY-927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson resolved VELOCITY-927.
-
Fix Version/s: 2.3
Resolution: Fixed
> Parsing problem with space before closing curly bracket
> ---
>
> Key: VELOCITY-927
> URL: https://issues.apache.org/jira/browse/VELOCITY-927
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.2
>Reporter: Al Bundy
>Assignee: Claude Brisson
>Priority: Major
> Fix For: 2.3
>
>
> After updateing from a slightly outdated velocity 1.x to 2.x wo have some
> issues with our existing templates.
> Some of them are already fixed in 2.2 but at least for now we still have one
> issue.
> This template
> {code:java}
> #set ( $nameMap10 =
> {
> }){code}
> results in
> {code:java}
> org.apache.velocity.runtime.parser.TemplateParseException: Encountered "}" at
> test[line 3, column 5]
> Was expecting one of:
> "[" ...
> "{" ...
> ...
> ...
> ...
> "true" ...
> "false" ...
> ...
> ...
> ...
> ...
> "{" ...
> "[" ...
> {code}
> it seems that the whitespaces and newlines in this example matter.
> Modifying the tempalte to
> {code:java}
> #set ( $nameMap10 =
> {})
> {code}
> seems to workaround this issue but it would be nice if this would be fixed in
> Velocity.
>
> Here is a small test-case:
> {code:java}
> @Test
> public void testEmptyMap()
> throws Exception
> {
> final String _empty_map = new StringBuilder()
> .append("#set ( $nameMap10 =\n")
> .append("{\n")
> .append("})\n")
> .toString();
> final Template _template = new Template();
> _template.setRuntimeServices(RuntimeSingleton.getRuntimeServices());
> _template.setEncoding(ModuleManager.getInstance().getDefaultEncoding());
> _template.setName("test");
> _template.setData(RuntimeSingleton.getRuntimeServices().parse(new
> StringReader(_empty_map.toString()), _template));
> _template.initDocument();
> final VelocityContext _context = new VelocityContext();
> _template.merge(_context, new StringWriter());
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-927) Parsing problem with space before closing curly bracket
[
https://issues.apache.org/jira/browse/VELOCITY-927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17292057#comment-17292057
]
Claude Brisson commented on VELOCITY-927:
-
Fixed in master.
> Parsing problem with space before closing curly bracket
> ---
>
> Key: VELOCITY-927
> URL: https://issues.apache.org/jira/browse/VELOCITY-927
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.2
>Reporter: Al Bundy
>Assignee: Claude Brisson
>Priority: Major
>
> After updateing from a slightly outdated velocity 1.x to 2.x wo have some
> issues with our existing templates.
> Some of them are already fixed in 2.2 but at least for now we still have one
> issue.
> This template
> {code:java}
> #set ( $nameMap10 =
> {
> }){code}
> results in
> {code:java}
> org.apache.velocity.runtime.parser.TemplateParseException: Encountered "}" at
> test[line 3, column 5]
> Was expecting one of:
> "[" ...
> "{" ...
> ...
> ...
> ...
> "true" ...
> "false" ...
> ...
> ...
> ...
> ...
> "{" ...
> "[" ...
> {code}
> it seems that the whitespaces and newlines in this example matter.
> Modifying the tempalte to
> {code:java}
> #set ( $nameMap10 =
> {})
> {code}
> seems to workaround this issue but it would be nice if this would be fixed in
> Velocity.
>
> Here is a small test-case:
> {code:java}
> @Test
> public void testEmptyMap()
> throws Exception
> {
> final String _empty_map = new StringBuilder()
> .append("#set ( $nameMap10 =\n")
> .append("{\n")
> .append("})\n")
> .toString();
> final Template _template = new Template();
> _template.setRuntimeServices(RuntimeSingleton.getRuntimeServices());
> _template.setEncoding(ModuleManager.getInstance().getDefaultEncoding());
> _template.setName("test");
> _template.setData(RuntimeSingleton.getRuntimeServices().parse(new
> StringReader(_empty_map.toString()), _template));
> _template.initDocument();
> final VelocityContext _context = new VelocityContext();
> _template.merge(_context, new StringWriter());
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Closed] (VELOCITY-935) Negation dos not work correctly after update from 1.6 to 2.2
[
https://issues.apache.org/jira/browse/VELOCITY-935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson closed VELOCITY-935.
---
> Negation dos not work correctly after update from 1.6 to 2.2
>
>
> Key: VELOCITY-935
> URL: https://issues.apache.org/jira/browse/VELOCITY-935
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.2
>Reporter: Al Bundy
>Assignee: Claude Brisson
>Priority: Major
>
> With 1.6 we used this
>
> {code:java}
> #if ( ! "$!testrun" == "true" )
> ...
> #end{code}
> This ensures that the code is only executed if current run is not a testrun
> ($testrun false or empty).
>
> Sine update to 2.2 this does not to work.
> In my case $testrun was false, but code was not executed.
> To get this to work I had to use brackets around the equals-check
> {code:java}
> #if ( ! ("$!testrun" == "true") )
> ...
> #end
> {code}
> This breaks the logic of a lot of templates...
--
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-935) Negation dos not work correctly after update from 1.6 to 2.2
[
https://issues.apache.org/jira/browse/VELOCITY-935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson resolved VELOCITY-935.
-
Resolution: Not A Bug
> Negation dos not work correctly after update from 1.6 to 2.2
>
>
> Key: VELOCITY-935
> URL: https://issues.apache.org/jira/browse/VELOCITY-935
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.2
>Reporter: Al Bundy
>Assignee: Claude Brisson
>Priority: Major
>
> With 1.6 we used this
>
> {code:java}
> #if ( ! "$!testrun" == "true" )
> ...
> #end{code}
> This ensures that the code is only executed if current run is not a testrun
> ($testrun false or empty).
>
> Sine update to 2.2 this does not to work.
> In my case $testrun was false, but code was not executed.
> To get this to work I had to use brackets around the equals-check
> {code:java}
> #if ( ! ("$!testrun" == "true") )
> ...
> #end
> {code}
> This breaks the logic of a lot of templates...
--
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-935) Negation dos not work correctly after update from 1.6 to 2.2
[
https://issues.apache.org/jira/browse/VELOCITY-935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17292043#comment-17292043
]
Claude Brisson commented on VELOCITY-935:
-
Notice added.
Expressions are converted to booleans when needed. Unary operators (like the
negation `!`) have a greater precedence than `==` and friends, and should be
evaluated first.
> Negation dos not work correctly after update from 1.6 to 2.2
>
>
> Key: VELOCITY-935
> URL: https://issues.apache.org/jira/browse/VELOCITY-935
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.2
>Reporter: Al Bundy
>Assignee: Claude Brisson
>Priority: Major
>
> With 1.6 we used this
>
> {code:java}
> #if ( ! "$!testrun" == "true" )
> ...
> #end{code}
> This ensures that the code is only executed if current run is not a testrun
> ($testrun false or empty).
>
> Sine update to 2.2 this does not to work.
> In my case $testrun was false, but code was not executed.
> To get this to work I had to use brackets around the equals-check
> {code:java}
> #if ( ! ("$!testrun" == "true") )
> ...
> #end
> {code}
> This breaks the logic of a lot of templates...
--
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-933) Spring support for Velocity
[ https://issues.apache.org/jira/browse/VELOCITY-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17291704#comment-17291704 ] Claude Brisson commented on VELOCITY-933: - [~michael-o] I'm not sure it's pertinent to mark this new module as either experimental or subject to change. After all it just found a new home, I just barely changed the logger. FYI, I have another working branch with the same for the Tools, but we're in a hurry to release so it won't be part of the next release yet. > Spring support for Velocity > --- > > Key: VELOCITY-933 > URL: https://issues.apache.org/jira/browse/VELOCITY-933 > Project: Velocity > Issue Type: Task > Components: Engine >Affects Versions: 2.3 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Major > Fix For: 2.3 > > Attachments: 2021-02-12 Vel 2.2 shows 1.7.png, Velocity Search > Results.png, image-2021-02-12-12-13-04-901.png > > > Add a new jar submodule for Velocity Spring support -- 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-933) Spring support for Velocity
[ https://issues.apache.org/jira/browse/VELOCITY-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17291635#comment-17291635 ] Claude Brisson commented on VELOCITY-933: - @Tim Where is this broken maven link? I must be searching in the wrong place... > Spring support for Velocity > --- > > Key: VELOCITY-933 > URL: https://issues.apache.org/jira/browse/VELOCITY-933 > Project: Velocity > Issue Type: Task > Components: Engine >Affects Versions: 2.3 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Major > Fix For: 2.3 > > Attachments: 2021-02-12 Vel 2.2 shows 1.7.png, Velocity Search > Results.png, image-2021-02-12-12-13-04-901.png > > > Add a new jar submodule for Velocity Spring support -- 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-935) Negation dos not work correctly after update from 1.6 to 2.2
[
https://issues.apache.org/jira/browse/VELOCITY-935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17291611#comment-17291611
]
Claude Brisson commented on VELOCITY-935:
-
I will add a notice to the upgrading page of the 2.x versions, but won't fix
it. Reverting to a broken operator precedence, even with a compatibility flag,
seems a no-go to me. Hopefully, you can track such uses in your templates with
the appropriate regex.
> Negation dos not work correctly after update from 1.6 to 2.2
>
>
> Key: VELOCITY-935
> URL: https://issues.apache.org/jira/browse/VELOCITY-935
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.2
>Reporter: Al Bundy
>Assignee: Claude Brisson
>Priority: Major
>
> With 1.6 we used this
>
> {code:java}
> #if ( ! "$!testrun" == "true" )
> ...
> #end{code}
> This ensures that the code is only executed if current run is not a testrun
> ($testrun false or empty).
>
> Sine update to 2.2 this does not to work.
> In my case $testrun was false, but code was not executed.
> To get this to work I had to use brackets around the equals-check
> {code:java}
> #if ( ! ("$!testrun" == "true") )
> ...
> #end
> {code}
> This breaks the logic of a lot of templates...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-931) SecureUberspector should block methods on ClassLoader and subclasses
[ https://issues.apache.org/jira/browse/VELOCITY-931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17291269#comment-17291269 ] Claude Brisson edited comment on VELOCITY-931 at 2/25/21, 10:35 PM: Merged in master. was (Author: claude): Merged un master. > SecureUberspector should block methods on ClassLoader and subclasses > > > Key: VELOCITY-931 > URL: https://issues.apache.org/jira/browse/VELOCITY-931 > Project: Velocity > Issue Type: Improvement >Reporter: William Glass-Husain >Assignee: William Glass-Husain >Priority: Major > Fix For: 2.3 > > > Currently, SecureUberspector matches classes stored with property > "introspector.restrict.classes", which includes ClassLoader. It then > matches exact class names and blocks all methods from being called on that > class. > However, in most cases it's actually a subclass of ClassLoader that's > available in the context, which under normal circumstances would not be > blocked. > My proposal – treat this as a special case. (Remove it from the > configuration). If the class being inspected is assignable from ClassLoader, > then block it. > You could make an argument that all the SecureUberspector should check if the > class isAssignable from all configured classes, but I am concerned about > possible performance penalties. I'd argue that we should hard code checks > for a few special internal classes but force the user to configure other > specific classes themselves. > -- 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-931) SecureUberspector should block methods on ClassLoader and subclasses
[ https://issues.apache.org/jira/browse/VELOCITY-931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson resolved VELOCITY-931. - Resolution: Fixed Merged un master. > SecureUberspector should block methods on ClassLoader and subclasses > > > Key: VELOCITY-931 > URL: https://issues.apache.org/jira/browse/VELOCITY-931 > Project: Velocity > Issue Type: Improvement >Reporter: William Glass-Husain >Assignee: William Glass-Husain >Priority: Major > Fix For: 2.3 > > > Currently, SecureUberspector matches classes stored with property > "introspector.restrict.classes", which includes ClassLoader. It then > matches exact class names and blocks all methods from being called on that > class. > However, in most cases it's actually a subclass of ClassLoader that's > available in the context, which under normal circumstances would not be > blocked. > My proposal – treat this as a special case. (Remove it from the > configuration). If the class being inspected is assignable from ClassLoader, > then block it. > You could make an argument that all the SecureUberspector should check if the > class isAssignable from all configured classes, but I am concerned about > possible performance penalties. I'd argue that we should hard code checks > for a few special internal classes but force the user to configure other > specific classes themselves. > -- 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-935) Negation dos not work correctly after update from 1.6 to 2.2
[
https://issues.apache.org/jira/browse/VELOCITY-935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17291265#comment-17291265
]
Claude Brisson commented on VELOCITY-935:
-
It looks more like a 1.6.x and 1.7 operator precedence bug.
We did the maximum to ensure backward compatibility, but please consider that
there is a major version change. Emulating previous version bugs is not that
fun.
> Negation dos not work correctly after update from 1.6 to 2.2
>
>
> Key: VELOCITY-935
> URL: https://issues.apache.org/jira/browse/VELOCITY-935
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.2
>Reporter: Al Bundy
>Assignee: Claude Brisson
>Priority: Major
>
> With 1.6 we used this
>
> {code:java}
> #if ( ! "$!testrun" == "true" )
> ...
> #end{code}
> This ensures that the code is only executed if current run is not a testrun
> ($testrun false or empty).
>
> Sine update to 2.2 this does not to work.
> In my case $testrun was false, but code was not executed.
> To get this to work I had to use brackets around the equals-check
> {code:java}
> #if ( ! ("$!testrun" == "true") )
> ...
> #end
> {code}
> This breaks the logic of a lot of templates...
--
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] [Assigned] (VELOCITY-935) Negation dos not work correctly after update from 1.6 to 2.2
[
https://issues.apache.org/jira/browse/VELOCITY-935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson reassigned VELOCITY-935:
---
Assignee: Claude Brisson
> Negation dos not work correctly after update from 1.6 to 2.2
>
>
> Key: VELOCITY-935
> URL: https://issues.apache.org/jira/browse/VELOCITY-935
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.2
>Reporter: Al Bundy
>Assignee: Claude Brisson
>Priority: Major
>
> With 1.6 we used this
>
> {code:java}
> #if ( ! "$!testrun" == "true" )
> ...
> #end{code}
> This ensures that the code is only executed if current run is not a testrun
> ($testrun false or empty).
>
> Sine update to 2.2 this does not to work.
> In my case $testrun was false, but code was not executed.
> To get this to work I had to brackets around the equals-check
> {code:java}
> #if ( ! ("$!testrun" == "true") )
> ...
> #end
> {code}
> This breaks the logic of a lot of templates...
--
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-935) Negation dos not work correctly after update from 1.6 to 2.2
[
https://issues.apache.org/jira/browse/VELOCITY-935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson closed VELOCITY-935.
---
> Negation dos not work correctly after update from 1.6 to 2.2
>
>
> Key: VELOCITY-935
> URL: https://issues.apache.org/jira/browse/VELOCITY-935
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.2
>Reporter: Al Bundy
>Priority: Major
>
> With 1.6 we used this
>
> {code:java}
> #if ( ! "$!testrun" == "true" )
> ...
> #end{code}
> This ensures that the code is only executed if current run is not a testrun
> ($testrun false or empty).
>
> Sine update to 2.2 this does not to work.
> In my case $testrun was false, but code was not executed.
> To get this to work I had to brackets around the equals-check
> {code:java}
> #if ( ! ("$!testrun" == "true") )
> ...
> #end
> {code}
> This breaks the logic of a lot of templates...
--
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-935) Negation dos not work correctly after update from 1.6 to 2.2
[
https://issues.apache.org/jira/browse/VELOCITY-935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17291238#comment-17291238
]
Claude Brisson commented on VELOCITY-935:
-
I ran all Velocity versions against the following template:
{code}
#set($testrun = false)
#if ( ! ("$!testrun" == "true") )
INSIDE
#end
{code}
and all versions printed `INSIDE`.
I cannot reproduce your problem.
> Negation dos not work correctly after update from 1.6 to 2.2
>
>
> Key: VELOCITY-935
> URL: https://issues.apache.org/jira/browse/VELOCITY-935
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.2
>Reporter: Al Bundy
>Priority: Major
>
> With 1.6 we used this
>
> {code:java}
> #if ( ! "$!testrun" == "true" )
> ...
> #end{code}
> This ensures that the code is only executed if current run is not a testrun
> ($testrun false or empty).
>
> Sine update to 2.2 this does not to work.
> In my case $testrun was false, but code was not executed.
> To get this to work I had to brackets around the equals-check
> {code:java}
> #if ( ! ("$!testrun" == "true") )
> ...
> #end
> {code}
> This breaks the logic of a lot of templates...
--
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-933) Spring support for Velocity
[ https://issues.apache.org/jira/browse/VELOCITY-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17284209#comment-17284209 ] Claude Brisson commented on VELOCITY-933: - > and further with opinion that templated pages have been replaced with REST + > JS. (Probably true, but not a suitable stack for personalized emails, > compared to a template engine.) That's partially true, but imagine a kotlin multiplatorm kotlin of Velocity, with an antlr grammar file which compiles to js... Big ideas but no time to work on them for me right now. > Spring support for Velocity > --- > > Key: VELOCITY-933 > URL: https://issues.apache.org/jira/browse/VELOCITY-933 > Project: Velocity > Issue Type: Task > Components: Engine >Affects Versions: 2.3 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Major > Fix For: 2.3 > > Attachments: 2021-02-12 Vel 2.2 shows 1.7.png, Velocity Search > Results.png, image-2021-02-12-12-13-04-901.png > > > Add a new jar submodule for Velocity Spring support -- 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-933) Spring support for Velocity
[ https://issues.apache.org/jira/browse/VELOCITY-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17284153#comment-17284153 ] Claude Brisson commented on VELOCITY-933: - By the way, the velocity-site repository now contains a builder/bin/builder.sh which makes it very easy to generate locally the site. > Spring support for Velocity > --- > > Key: VELOCITY-933 > URL: https://issues.apache.org/jira/browse/VELOCITY-933 > Project: Velocity > Issue Type: Task > Components: Engine >Affects Versions: 2.3 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Major > Fix For: 2.3 > > Attachments: 2021-02-12 Vel 2.2 shows 1.7.png, Velocity Search > Results.png, image-2021-02-12-12-13-04-901.png > > > Add a new jar submodule for Velocity Spring support -- 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-907) Moderators needed for general list
[ https://issues.apache.org/jira/browse/VELOCITY-907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17284152#comment-17284152 ] Claude Brisson commented on VELOCITY-907: - I didn't get any update from Sebb. I'll ping him. > Moderators needed for general list > -- > > Key: VELOCITY-907 > URL: https://issues.apache.org/jira/browse/VELOCITY-907 > Project: Velocity > Issue Type: Bug >Reporter: Sebb >Priority: Major > > There are currently no moderators for the -commits@- or general@ lists [1] > Some volunteers need to step up. > In the meantime I have added myself, but that can only be temporary. > [1] > [https://whimsy.apache.org/roster/committee/velocity#mail|https://whimsy.apache.org/roster/committee/santuario#mail] -- 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-921) Add syntactic sugar for maps handling in #foreach
[ https://issues.apache.org/jira/browse/VELOCITY-921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17284151#comment-17284151 ] Claude Brisson commented on VELOCITY-921: - It hasn't been discussed so far. I would let it open for now as a reminder... > Add syntactic sugar for maps handling in #foreach > - > > Key: VELOCITY-921 > URL: https://issues.apache.org/jira/browse/VELOCITY-921 > Project: Velocity > Issue Type: New Feature > Components: Engine >Affects Versions: 2.2 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Major > > `#foreach($x in $map) defaults to iterating on map values. But what if we > have to iterate on keys or on entries? Resorting to write #foreach($k in > $map.keySet()) or #foreach($e in $map.entrySet()) always bothered me. Most of > the time with maps, we'll want to iterate over keys or entries. > The proposal is to introduce optional postfixed modifiers in the #foreach > syntax, as follow: > #foreach($k in $map entries) > #foreach($k in $map keys) > #foreach($k in $map values) > the default being kept on values, as it is today. Applying the modifiers on > anything else than a map would give an error. -- 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-933) Spring support for Velocity
[ https://issues.apache.org/jira/browse/VELOCITY-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17284147#comment-17284147 ] Claude Brisson commented on VELOCITY-933: - I fixed the links and the mention of 1.7. FYI, the velocity-site now contains a dockerized builder that generates the site using a single shell script. I created a ticket on infra for the wiki edition: https://issues.apache.org/jira/browse/INFRA-21418 Yes, there would be a lot to do about documentation... > Spring support for Velocity > --- > > Key: VELOCITY-933 > URL: https://issues.apache.org/jira/browse/VELOCITY-933 > Project: Velocity > Issue Type: Task > Components: Engine >Affects Versions: 2.3 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Major > Fix For: 2.3 > > Attachments: 2021-02-12 Vel 2.2 shows 1.7.png, Velocity Search > Results.png, image-2021-02-12-12-13-04-901.png > > > Add a new jar submodule for Velocity Spring support -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-934) NullPointerException under high concurrency
[
https://issues.apache.org/jira/browse/VELOCITY-934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17232419#comment-17232419
]
Claude Brisson edited comment on VELOCITY-934 at 11/15/20, 11:07 PM:
-
The design choices never changed: the engine is threadsafe, but the context
isn't. We might expect that contexts become threadsafe when used in a read-only
mode, alas it's not the case with the current code.
The concurrent modifications that pose a problem here are a mechanism by which
directives (`#foreach` in this case) put their own scope (`$foreach`) in the
context before rendering and remove it afterwards.
I see two workarounds:
1. If the `$foreach` scope is not needed, it's possible to deactivate it using
the setting `context.scope_control.foreach = false`.
2. If it is needed (which is the case here), the natural workaround is to use a
wrapping context:
{code:java}
@Benchmark
public String benchmark() {
Writer writer = new StringWriter();
template.merge(new VelocityContext(context), writer);
return writer.toString();
}
{code}
Please note that the initial context content will *not* be copied, only wrapped
as an inner context in the new one (this is not a copy constructor).
My proposal is to add those details to the documentation.
was (Author: claude):
The design choices never changed: the engine is threadsafe, but the context
isn't. We might expect that contexts become threadsafe when used in a read-only
mode, alas it's not the case with the current code.
The concurrent modifications that pose a problem here are a mechanism by which
directives (`#foreach` in this case) put their own scope (`$foreach`) in the
context before rendering and remove it afterwards.
I see two workarounds:
1. If the `$foreach` scope is not needed, it's possible to deactivate it using
the setting `context.scope_control.foreach = false`.
2. If it is needed (which is the case here), the natural workaround is to use a
wrapping context:
@Benchmark
public String benchmark() {
Writer writer = new StringWriter();
template.merge(new VelocityContext(context), writer);
return writer.toString();
}
Please note that the initial context content will *not* be copied, only wrapped
as an inner context in the new one (this is not a copy constructor).
My proposal is to add those details to the documentation.
> NullPointerException under high concurrency
> ---
>
> Key: VELOCITY-934
> URL: https://issues.apache.org/jira/browse/VELOCITY-934
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 1.7.x, 2.2
> Environment: Windows 10 Professional
>Reporter: Andreas Hager
>Priority: Major
>
> I adjusted the mboseke/template-benchmark to profile throughput on AMD Ryzen
> 5950x:
> [https://github.com/casid/template-benchmark/tree/ryzen-5950x]
> With 32 concurrent threads, I can reliably reproduce a runtime exception in
> the Apache Velocity benchmark:
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.velocity.runtime.directive.Directive.postRender(Directive.java:240)
> at
> org.apache.velocity.runtime.directive.Foreach.clean(Foreach.java:325)
> at
> org.apache.velocity.runtime.directive.Foreach.render(Foreach.java:292)
> at
> org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:301)
> at
> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:423)
> at org.apache.velocity.Template.merge(Template.java:358)
> at org.apache.velocity.Template.merge(Template.java:262)
> at com.mitchellbosecke.benchmark.Velocity.benchmark(Velocity.java:34)
> at
> com.mitchellbosecke.benchmark.generated.Velocity_benchmark_jmhTest.benchmark_thrpt_jmhStub(Velocity_benchmark_jmhTest.java:122)
> at
> com.mitchellbosecke.benchmark.generated.Velocity_benchmark_jmhTest.benchmark_Throughput(Velocity_benchmark_jmhTest.java:69)
> at jdk.internal.reflect.GeneratedMethodAccessor1.invoke(Unknown
> Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.openjdk.jmh.runner.BenchmarkHandler$BenchmarkTask.call(BenchmarkHandler.java:430)
> at
> org.openjdk.jmh.runner.BenchmarkHandler$BenchmarkTask.call(BenchmarkHandler.java:412)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
>
[jira] [Commented] (VELOCITY-934) NullPointerException under high concurrency
[
https://issues.apache.org/jira/browse/VELOCITY-934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17232419#comment-17232419
]
Claude Brisson commented on VELOCITY-934:
-
The design choices never changed: the engine is threadsafe, but the context
isn't. We might expect that contexts become threadsafe when used in a read-only
mode, alas it's not the case with the current code.
The concurrent modifications that pose a problem here are a mechanism by which
directives (`#foreach` in this case) put their own scope (`$foreach`) in the
context before rendering and remove it afterwards.
I see two workarounds:
1. If the `$foreach` scope is not needed, it's possible to deactivate it using
the setting `context.scope_control.foreach = false`.
2. If it is needed (which is the case here), the natural workaround is to use a
wrapping context:
@Benchmark
public String benchmark() {
Writer writer = new StringWriter();
template.merge(new VelocityContext(context), writer);
return writer.toString();
}
Please note that the initial context content will *not* be copied, only wrapped
as an inner context in the new one (this is not a copy constructor).
My proposal is to add those details to the documentation.
> NullPointerException under high concurrency
> ---
>
> Key: VELOCITY-934
> URL: https://issues.apache.org/jira/browse/VELOCITY-934
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 1.7.x, 2.2
> Environment: Windows 10 Professional
>Reporter: Andreas Hager
>Priority: Major
>
> I adjusted the mboseke/template-benchmark to profile throughput on AMD Ryzen
> 5950x:
> [https://github.com/casid/template-benchmark/tree/ryzen-5950x]
> With 32 concurrent threads, I can reliably reproduce a runtime exception in
> the Apache Velocity benchmark:
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.velocity.runtime.directive.Directive.postRender(Directive.java:240)
> at
> org.apache.velocity.runtime.directive.Foreach.clean(Foreach.java:325)
> at
> org.apache.velocity.runtime.directive.Foreach.render(Foreach.java:292)
> at
> org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:301)
> at
> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:423)
> at org.apache.velocity.Template.merge(Template.java:358)
> at org.apache.velocity.Template.merge(Template.java:262)
> at com.mitchellbosecke.benchmark.Velocity.benchmark(Velocity.java:34)
> at
> com.mitchellbosecke.benchmark.generated.Velocity_benchmark_jmhTest.benchmark_thrpt_jmhStub(Velocity_benchmark_jmhTest.java:122)
> at
> com.mitchellbosecke.benchmark.generated.Velocity_benchmark_jmhTest.benchmark_Throughput(Velocity_benchmark_jmhTest.java:69)
> at jdk.internal.reflect.GeneratedMethodAccessor1.invoke(Unknown
> Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.openjdk.jmh.runner.BenchmarkHandler$BenchmarkTask.call(BenchmarkHandler.java:430)
> at
> org.openjdk.jmh.runner.BenchmarkHandler$BenchmarkTask.call(BenchmarkHandler.java:412)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {code}
> This initially happened with version 1.7, but after updating to 2.2 the
> problem is still there. It looks like there is some threading issue under
> high concurrency.
> This is the velocity benchmark class:
> [https://github.com/casid/template-benchmark/blob/ryzen-5950x/src/main/java/com/mitchellbosecke/benchmark/Velocity.java]
> And this is the velocity template:
> [https://github.com/casid/template-benchmark/blob/ryzen-5950x/src/main/resources/templates/stocks.velocity.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-933) Spring support for Velocity
[ https://issues.apache.org/jira/browse/VELOCITY-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17221651#comment-17221651 ] Claude Brisson commented on VELOCITY-933: - [~michael-o] It is a mere adaptation of the code they dropped, yes. It now uses engine 2.x resource readers and slf4j logger, and that's all I did. Not being a big Spring user, I don't really know if there is something else to take into account. As a side note, I'm quite surprised nobody proposed this adaptation sooner. > Spring support for Velocity > --- > > Key: VELOCITY-933 > URL: https://issues.apache.org/jira/browse/VELOCITY-933 > Project: Velocity > Issue Type: Task > Components: Engine >Affects Versions: 2.3 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Major > Fix For: 2.3 > > > Add a new jar submodule for Velocity Spring support -- 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-933) Spring support for Velocity
[ https://issues.apache.org/jira/browse/VELOCITY-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17221427#comment-17221427 ] Claude Brisson commented on VELOCITY-933: - Pushed in velocity-spring-support branch. Reviews are welcome. Note that I also have a velocity-tools-spring-support in the pipe, but some work left to do on it. > Spring support for Velocity > --- > > Key: VELOCITY-933 > URL: https://issues.apache.org/jira/browse/VELOCITY-933 > Project: Velocity > Issue Type: Task > Components: Engine >Affects Versions: 2.3 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Major > Fix For: 2.3 > > > Add a new jar submodule for Velocity Spring support -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Created] (VELOCITY-933) Spring support for Velocity
Claude Brisson created VELOCITY-933: --- Summary: Spring support for Velocity Key: VELOCITY-933 URL: https://issues.apache.org/jira/browse/VELOCITY-933 Project: Velocity Issue Type: Task Components: Engine Affects Versions: 2.3 Reporter: Claude Brisson Assignee: Claude Brisson Fix For: 2.3 Add a new jar submodule for Velocity Spring support -- 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-930) Link to Issue Tracker is broken
[
https://issues.apache.org/jira/browse/VELOCITY-930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson resolved VELOCITY-930.
-
Assignee: Claude Brisson
Resolution: Fixed
Thanks for the report. The fix is online.
> Link to Issue Tracker is broken
> ---
>
> Key: VELOCITY-930
> URL: https://issues.apache.org/jira/browse/VELOCITY-930
> Project: Velocity
> Issue Type: Bug
> Components: Website
>Reporter: Kai Bächle
>Assignee: Claude Brisson
>Priority: Minor
>
> The link to this issue tracker at [https://velocity.apache.org/engine/2.2/]
> "There's a list of issues waiting to be addressed in {color:#de350b}our bug
> tracker{color}."
> points to https://issues.apache.org/jira/browse/VELOCITY%22 and should point
> to https://issues.apache.org/jira/browse/VELOCITY
--
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-930) Link to Issue Tracker is broken
[
https://issues.apache.org/jira/browse/VELOCITY-930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson closed VELOCITY-930.
---
> Link to Issue Tracker is broken
> ---
>
> Key: VELOCITY-930
> URL: https://issues.apache.org/jira/browse/VELOCITY-930
> Project: Velocity
> Issue Type: Bug
> Components: Website
>Reporter: Kai Bächle
>Assignee: Claude Brisson
>Priority: Minor
>
> The link to this issue tracker at [https://velocity.apache.org/engine/2.2/]
> "There's a list of issues waiting to be addressed in {color:#de350b}our bug
> tracker{color}."
> points to https://issues.apache.org/jira/browse/VELOCITY%22 and should point
> to https://issues.apache.org/jira/browse/VELOCITY
--
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] (VELTOOLS-186) Review shared VelocityView initialization error handling
[ https://issues.apache.org/jira/browse/VELTOOLS-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17054507#comment-17054507 ] Claude Brisson commented on VELTOOLS-186: - > If this one is shared, shouldn't a listener rather create this instance and > not a servlet? It's a lazy initialization process, the shared view is built the first time it is needed. That's fine this way, since a servlet or a filter relying on the view cannot do much without it. We should just ensure there's only one attempt. > What if someone wants to views differently configured? That's taken in to account. Servlets use the shared view by default but can use their own. > Review shared VelocityView initialization error handling > > > Key: VELTOOLS-186 > URL: https://issues.apache.org/jira/browse/VELTOOLS-186 > Project: Velocity Tools > Issue Type: Bug > Components: VelocityView >Affects Versions: 3.0 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Minor > > When VelocityView instanciation fails (aka throws an unrecoverable > exception), it is attempted again as many times as there are servlets or > filters relying on it, even when the instance is supposed to be shared. > The proper behavior would be to somehow mark the shared instance attribute as > being invalid (but not null). -- 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] (VELTOOLS-186) Review shared VelocityView initialization error handling
[ https://issues.apache.org/jira/browse/VELTOOLS-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17054500#comment-17054500 ] Claude Brisson commented on VELTOOLS-186: - The would-be-shared instance never gets a chance to be stored as a webapp context attribute as it is meant to, so a new instance is allocated (and dropped) every time. > Review shared VelocityView initialization error handling > > > Key: VELTOOLS-186 > URL: https://issues.apache.org/jira/browse/VELTOOLS-186 > Project: Velocity Tools > Issue Type: Bug > Components: VelocityView >Affects Versions: 3.0 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Minor > > When VelocityView instanciation fails (aka throws an unrecoverable > exception), it is attempted again as many times as there are servlets or > filters relying on it, even when the instance is supposed to be shared. > The proper behavior would be to somehow mark the shared instance attribute as > being invalid (but not null). -- 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] (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 resolved VELTOOLS-187. - Fix Version/s: 3.1 Resolution: Fixed Fixed by commit 1874970. > 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.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Resolved] (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 resolved VELTOOLS-185. - Fix Version/s: 3.1 Resolution: Fixed Patch applied. Thanks. > 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.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Assigned] (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 reassigned VELTOOLS-185: --- Assignee: Claude Brisson > 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 > 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.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-928) Velocity parse error
[
https://issues.apache.org/jira/browse/VELOCITY-928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17042800#comment-17042800
]
Claude Brisson commented on VELOCITY-928:
-
The parser doesn't support parsing unbalanced expressions that _could_ be VTL...
What you can do is protect the expression from being parsed:
{code}
#[[$a.r(a]]#
{code}
> Velocity parse error
>
>
> Key: VELOCITY-928
> URL: https://issues.apache.org/jira/browse/VELOCITY-928
> Project: Velocity
> Issue Type: Bug
>Affects Versions: 2.0, 2.1
>Reporter: 郑剑峰
>Priority: Major
>
> hi
> Velocity to evaluate the string template "$a.r(a" , it throw an exception
> ERROR org.apache.velocity.parser - appmd: Encountered "" at line 1,
> column 6.
> Was expecting one of:
> "[" ...
> "," ...
> ")" ...
> ...
> ...
> "-" ...
> "+" ...
> "*" ...
> "/" ...
> "%" ...
> ...
> ...
> ...
> ...
> ...
> ...
> ...
> ...
> change the template to "/$a.r(a" the error still,and "//$a.r(a" still
> and the "$a.r(a)" is a raw string not a expression
> but i change the template to "$a.r(a)" it's ok
> Looking forward to getting reply. Thanks.
--
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] [Assigned] (VELOCITY-927) Parsing problem with space before closing curly bracket
[
https://issues.apache.org/jira/browse/VELOCITY-927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson reassigned VELOCITY-927:
---
Assignee: Claude Brisson
> Parsing problem with space before closing curly bracket
> ---
>
> Key: VELOCITY-927
> URL: https://issues.apache.org/jira/browse/VELOCITY-927
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.2
>Reporter: Al Bundy
>Assignee: Claude Brisson
>Priority: Major
>
> After updateing from a slightly outdated velocity 1.x to 2.x wo have some
> issues with our existing templates.
> Some of them are already fixed in 2.2 but at least for now we still have one
> issue.
> This template
> {code:java}
> #set ( $nameMap10 =
> {
> }){code}
> results in
> {code:java}
> org.apache.velocity.runtime.parser.TemplateParseException: Encountered "}" at
> test[line 3, column 5]
> Was expecting one of:
> "[" ...
> "{" ...
> ...
> ...
> ...
> "true" ...
> "false" ...
> ...
> ...
> ...
> ...
> "{" ...
> "[" ...
> {code}
> it seems that the whitespaces and newlines in this example matter.
> Modifying the tempalte to
> {code:java}
> #set ( $nameMap10 =
> {})
> {code}
> seems to workaround this issue but it would be nice if this would be fixed in
> Velocity.
>
> Here is a small test-case:
> {code:java}
> @Test
> public void testEmptyMap()
> throws Exception
> {
> final String _empty_map = new StringBuilder()
> .append("#set ( $nameMap10 =\n")
> .append("{\n")
> .append("})\n")
> .toString();
> final Template _template = new Template();
> _template.setRuntimeServices(RuntimeSingleton.getRuntimeServices());
> _template.setEncoding(ModuleManager.getInstance().getDefaultEncoding());
> _template.setName("test");
> _template.setData(RuntimeSingleton.getRuntimeServices().parse(new
> StringReader(_empty_map.toString()), _template));
> _template.initDocument();
> final VelocityContext _context = new VelocityContext();
> _template.merge(_context, new StringWriter());
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-927) Parsing problem with space before closing curly bracket
[
https://issues.apache.org/jira/browse/VELOCITY-927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson updated VELOCITY-927:
Summary: Parsing problem with space before closing curly bracket (was:
Compatibility to Velocity 1.x)
> Parsing problem with space before closing curly bracket
> ---
>
> Key: VELOCITY-927
> URL: https://issues.apache.org/jira/browse/VELOCITY-927
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.2
>Reporter: Al Bundy
>Priority: Major
>
> After updateing from a slightly outdated velocity 1.x to 2.x wo have some
> issues with our existing templates.
> Some of them are already fixed in 2.2 but at least for now we still have one
> issue.
> This template
> {code:java}
> #set ( $nameMap10 =
> {
> }){code}
> results in
> {code:java}
> org.apache.velocity.runtime.parser.TemplateParseException: Encountered "}" at
> test[line 3, column 5]
> Was expecting one of:
> "[" ...
> "{" ...
> ...
> ...
> ...
> "true" ...
> "false" ...
> ...
> ...
> ...
> ...
> "{" ...
> "[" ...
> {code}
> it seems that the whitespaces and newlines in this example matter.
> Modifying the tempalte to
> {code:java}
> #set ( $nameMap10 =
> {})
> {code}
> seems to workaround this issue but it would be nice if this would be fixed in
> Velocity.
>
> Here is a small test-case:
> {code:java}
> @Test
> public void testEmptyMap()
> throws Exception
> {
> final String _empty_map = new StringBuilder()
> .append("#set ( $nameMap10 =\n")
> .append("{\n")
> .append("})\n")
> .toString();
> final Template _template = new Template();
> _template.setRuntimeServices(RuntimeSingleton.getRuntimeServices());
> _template.setEncoding(ModuleManager.getInstance().getDefaultEncoding());
> _template.setName("test");
> _template.setData(RuntimeSingleton.getRuntimeServices().parse(new
> StringReader(_empty_map.toString()), _template));
> _template.initDocument();
> final VelocityContext _context = new VelocityContext();
> _template.merge(_context, new StringWriter());
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-926) Regression: Macro arguments names cannot collide with external references names
[
https://issues.apache.org/jira/browse/VELOCITY-926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17025036#comment-17025036
]
Claude Brisson commented on VELOCITY-926:
-
[~tmortagne], would you be kind enough to test this snapshot version before I
push out the RC? Thanks.
> Regression: Macro arguments names cannot collide with external references
> names
> ---
>
> Key: VELOCITY-926
> URL: https://issues.apache.org/jira/browse/VELOCITY-926
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.0, 2.1
>Reporter: Claude Brisson
>Assignee: Claude Brisson
>Priority: Major
> Fix For: 2.2
>
>
> Consider the following example:
> {code}
> #macro( test $foo $bar )
> $foo $bar
> #end
> #set($foo = 'foo')
> #set($bar = 'bar')
> #test( $bar, $foo )
> {code}
> The expected result would be "{{bar foo}}", but since 2.0 we get the
> incorrect result "{{bar bar}}", as if the first inner {{$foo}} macro argument
> was overwritting the second argument evaluation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Resolved] (VELOCITY-926) Regression: Macro arguments names cannot collide with external references names
[
https://issues.apache.org/jira/browse/VELOCITY-926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson resolved VELOCITY-926.
-
Resolution: Fixed
Fixed by commit 1873244.
Deprecate velocimacro.arguments.preserve_literals in favor of the new
{{velocimacro.enable_bc_mode flag,
which mimics 1.7 velocimacro behavior:
- preserve arguments literals:
#macro(m $arg) $arg #end
m($null)
will displays $arg w/o bc mode and $null with bc mode
- use global defaults for missing arguments:
#macro(m $foo) $foo #end
#set($foo='foo')
#m()
will display $foo w/o bc mode and 'foo' with bc mode
The following use cases have been left aside from backward compatibility:
- preserving local macro scope values
#macro(test) #set($foo = 'foo')
$some_tool.change_foo_value_in_global_context_to_bar() $foo #end
#test()
will always display 'bar', while 1.7 displayed 'foo'
- setting a null argument to null, while argument name exists in context,
#macro(setnull $foo) #set($foo = $null) #end
#set($foo='foo')
#setnull($null)
$foo
Will always display 'foo' (w or w/o bc mode), while 1.7 did display $foo
> Regression: Macro arguments names cannot collide with external references
> names
> ---
>
> Key: VELOCITY-926
> URL: https://issues.apache.org/jira/browse/VELOCITY-926
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.0, 2.1
>Reporter: Claude Brisson
>Assignee: Claude Brisson
>Priority: Major
> Fix For: 2.2
>
>
> Consider the following example:
> {code}
> #macro( test $foo $bar )
> $foo $bar
> #end
> #set($foo = 'foo')
> #set($bar = 'bar')
> #test( $bar, $foo )
> {code}
> The expected result would be "{{bar foo}}", but since 2.0 we get the
> incorrect result "{{bar bar}}", as if the first inner {{$foo}} macro argument
> was overwritting the second argument evaluation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-926) Regression: Macro arguments names cannot collide with external references names
[
https://issues.apache.org/jira/browse/VELOCITY-926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024549#comment-17024549
]
Claude Brisson edited comment on VELOCITY-926 at 1/28/20 6:40 AM:
--
When a naming collision occurs, there is a side effect which is that in 1.7,
global context values become default values for *missing* macro arguments.
Two people reported usecases where backward compatibility was broken because of
this 1.7 _undocumented feature_, so it's worth addressing.
The plan is to deprecate the 2.1 flag
{{velocimacro.arguments.preserve_literals}} in favor of a new
{{velocimacro.enable_bc_mode}} flag which would :
* preserve arguments literals
* allow global values as defaults for missing arguments
* -also allow a macro to set to null a reference in the global context by
setting one of its arguments to null (setting a global reference this way is
allowed in 2.x but not for null values)- (let's leave out this one and revert
the _standard_ behavior to also allow setting nulls by default, it was just a
side effect of fixing VELOCITY-904 with commit 1871332)
was (Author: claude):
When a naming collision occurs, there is a side effect which is that in 1.7,
global context values become default values for *missing* macro arguments.
Two people reported usecases where backward compatibility was broken because of
this 1.7 _undocumented feature_, so it's worth addressing.
The plan is to deprecate the 2.1 flag
{{velocimacro.arguments.preserve_literals}} in favor of a new
{{velocimacro.enable_bc_mode}} flag which would :
* preserve arguments literals
* allow global values as defaults for missing arguments
* also allow a macro to set to null a reference in the global context by
setting one of its arguments to null (setting a global reference this way is
allowed in 2.x but not for null values)
> Regression: Macro arguments names cannot collide with external references
> names
> ---
>
> Key: VELOCITY-926
> URL: https://issues.apache.org/jira/browse/VELOCITY-926
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.0, 2.1
>Reporter: Claude Brisson
>Assignee: Claude Brisson
>Priority: Major
> Fix For: 2.2
>
>
> Consider the following example:
> {code}
> #macro( test $foo $bar )
> $foo $bar
> #end
> #set($foo = 'foo')
> #set($bar = 'bar')
> #test( $bar, $foo )
> {code}
> The expected result would be "{{bar foo}}", but since 2.0 we get the
> incorrect result "{{bar bar}}", as if the first inner {{$foo}} macro argument
> was overwritting the second argument evaluation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Reopened] (VELOCITY-926) Regression: Macro arguments names cannot collide with external references names
[
https://issues.apache.org/jira/browse/VELOCITY-926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson reopened VELOCITY-926:
-
When a naming collision occurs, there is a side effect which is that in 1.7,
global context values become default values for *missing* macro arguments.
Two people reported usecases where backward compatibility was broken because of
this 1.7 _undocumented feature_, so it's worth addressing.
The plan is to deprecate the 2.1 flag
{{velocimacro.arguments.preserve_literals}} in favor of a new
{{velocimacro.enable_bc_mode}} flag which would :
* preserve arguments literals
* allow global values as defaults for missing arguments
* also allow a macro to set to null a reference in the global context by
setting one of its arguments to null (setting a global reference this way is
allowed in 2.x but not for null values)
> Regression: Macro arguments names cannot collide with external references
> names
> ---
>
> Key: VELOCITY-926
> URL: https://issues.apache.org/jira/browse/VELOCITY-926
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.0, 2.1
>Reporter: Claude Brisson
>Assignee: Claude Brisson
>Priority: Major
> Fix For: 2.2
>
>
> Consider the following example:
> {code}
> #macro( test $foo $bar )
> $foo $bar
> #end
> #set($foo = 'foo')
> #set($bar = 'bar')
> #test( $bar, $foo )
> {code}
> The expected result would be "{{bar foo}}", but since 2.0 we get the
> incorrect result "{{bar bar}}", as if the first inner {{$foo}} macro argument
> was overwritting the second argument evaluation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-926) Regression: Macro arguments names cannot collide with external references names
[
https://issues.apache.org/jira/browse/VELOCITY-926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024414#comment-17024414
]
Claude Brisson commented on VELOCITY-926:
-
What I'm ready to do is review the compatibility option(s) so that global
values provide defaults for missing arguments. It looks like you are not the
only ones hitting this problem, as Greg Huber reported a similar one. That
should fix the recently found differences. I don't know yet if it will be a new
{{velocimacro.arguments.global_defaults}} or if it is preferable to deprecate
{{velocimacro.arguments.preserve_literals}} and gather both BC behaviors in a
new {{velocimacro_enable_bc_mode}} flag. The later has the advantage that it
can incorporate other adjustments, like a macro being able to set to null a
global reference by setting to null an argument with the same name.
What is certain is that reinserting the ProxyVMContext is to be avoided. It had
been identified as a major performance bottleneck, and removed for a reason. So
beyond the behaviors that won't be emulated is the usecase where you expect a
macro to keep its locally set values even if they are modified by external
macros or parsings.
> Regression: Macro arguments names cannot collide with external references
> names
> ---
>
> Key: VELOCITY-926
> URL: https://issues.apache.org/jira/browse/VELOCITY-926
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.0, 2.1
>Reporter: Claude Brisson
>Assignee: Claude Brisson
>Priority: Major
> Fix For: 2.2
>
>
> Consider the following example:
> {code}
> #macro( test $foo $bar )
> $foo $bar
> #end
> #set($foo = 'foo')
> #set($bar = 'bar')
> #test( $bar, $foo )
> {code}
> The expected result would be "{{bar foo}}", but since 2.0 we get the
> incorrect result "{{bar bar}}", as if the first inner {{$foo}} macro argument
> was overwritting the second argument evaluation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-926) Regression: Macro arguments names cannot collide with external references names
[
https://issues.apache.org/jira/browse/VELOCITY-926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17023269#comment-17023269
]
Claude Brisson commented on VELOCITY-926:
-
[~surli] I did not observe the behavior you mention, with or without
{{velocimacro.arguments.preserve_literals}} set to true. You may want to
provide me with a more circumstanced example, including the whole Velocity
configuration. This behavior would be a serious bug.
[~tmortagne] Yes, any change affects backward compatibility. But when they
concern ill-formed constructs, like expecting the global value of a reference
to magically become a default value for a missing argument, we can question the
decision to provide backward compatibility. That's why I was asking for a
specific use case where this behavior would be useful, as opposed to just
supposing that it could perhaps break something somewhere. Again, since we're
*not* passing the argument, there is a strong logic in the fact that it remains
null inside the macro.
> Regression: Macro arguments names cannot collide with external references
> names
> ---
>
> Key: VELOCITY-926
> URL: https://issues.apache.org/jira/browse/VELOCITY-926
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.0, 2.1
>Reporter: Claude Brisson
>Assignee: Claude Brisson
>Priority: Major
> Fix For: 2.2
>
>
> Consider the following example:
> {code}
> #macro( test $foo $bar )
> $foo $bar
> #end
> #set($foo = 'foo')
> #set($bar = 'bar')
> #test( $bar, $foo )
> {code}
> The expected result would be "{{bar foo}}", but since 2.0 we get the
> incorrect result "{{bar bar}}", as if the first inner {{$foo}} macro argument
> was overwritting the second argument evaluation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Resolved] (VELOCITY-926) Regression: Macro arguments names cannot collide with external references names
[
https://issues.apache.org/jira/browse/VELOCITY-926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson resolved VELOCITY-926.
-
Resolution: Fixed
Resolved by commit 1873069.
Thanks again to Thomas Mortagne for finding this bug.
> Regression: Macro arguments names cannot collide with external references
> names
> ---
>
> Key: VELOCITY-926
> URL: https://issues.apache.org/jira/browse/VELOCITY-926
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.0, 2.1
>Reporter: Claude Brisson
>Assignee: Claude Brisson
>Priority: Major
>
> Consider the following example:
> {code}
> #macro( test $foo $bar )
> $foo $bar
> #end
> #set($foo = 'foo')
> #set($bar = 'bar')
> #test( $bar, $foo )
> {code}
> The expected result would be "{{bar foo}}", but since 2.0 we get the
> incorrect result "{{bar bar}}", as if the first inner {{$foo}} macro argument
> was overwritting the second argument evaluation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-926) Regression: Macro arguments names cannot collide with external references names
[
https://issues.apache.org/jira/browse/VELOCITY-926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson updated VELOCITY-926:
Fix Version/s: 2.2
> Regression: Macro arguments names cannot collide with external references
> names
> ---
>
> Key: VELOCITY-926
> URL: https://issues.apache.org/jira/browse/VELOCITY-926
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.0, 2.1
>Reporter: Claude Brisson
>Assignee: Claude Brisson
>Priority: Major
> Fix For: 2.2
>
>
> Consider the following example:
> {code}
> #macro( test $foo $bar )
> $foo $bar
> #end
> #set($foo = 'foo')
> #set($bar = 'bar')
> #test( $bar, $foo )
> {code}
> The expected result would be "{{bar foo}}", but since 2.0 we get the
> incorrect result "{{bar bar}}", as if the first inner {{$foo}} macro argument
> was overwritting the second argument evaluation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-926) Regression: Macro arguments names cannot collide with external references names
[
https://issues.apache.org/jira/browse/VELOCITY-926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson updated VELOCITY-926:
Description:
Consider the following example:
{code}
#macro( test $foo $bar )
$foo $bar
#end
#set($foo = 'foo')
#set($bar = 'bar')
#test( $bar, $foo )
{code}
The expected result would be "{{bar foo}}", but since 2.0 we get the incorrect
result "{{bar bar}}", as if the first inner {{$foo}} macro argument was
overwritting the second argument evaluation.
was:
Consider the following example:
{{code}}
#macro( test $foo $bar )
$foo $bar
#end
#set($foo = 'foo')
#set($bar = 'bar')
#test( $bar, $foo )
{{code}}
The expected result would be {{code}}bar foo{{code}}, but since 2.0 we get the
incorrect result {{code}}bar bar{{code}}, as if the first inner
{{code}}$foo{{code}} macro argument was overwritting the second argument
evaluation.
> Regression: Macro arguments names cannot collide with external references
> names
> ---
>
> Key: VELOCITY-926
> URL: https://issues.apache.org/jira/browse/VELOCITY-926
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.0, 2.1
>Reporter: Claude Brisson
>Assignee: Claude Brisson
>Priority: Major
>
> Consider the following example:
> {code}
> #macro( test $foo $bar )
> $foo $bar
> #end
> #set($foo = 'foo')
> #set($bar = 'bar')
> #test( $bar, $foo )
> {code}
> The expected result would be "{{bar foo}}", but since 2.0 we get the
> incorrect result "{{bar bar}}", as if the first inner {{$foo}} macro argument
> was overwritting the second argument evaluation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Created] (VELOCITY-926) Regression: Macro arguments names cannot collide with external references names
Claude Brisson created VELOCITY-926:
---
Summary: Regression: Macro arguments names cannot collide with
external references names
Key: VELOCITY-926
URL: https://issues.apache.org/jira/browse/VELOCITY-926
Project: Velocity
Issue Type: Bug
Components: Engine
Affects Versions: 2.1, 2.0
Reporter: Claude Brisson
Assignee: Claude Brisson
Consider the following example:
{{code}}
#macro( test $foo $bar )
$foo $bar
#end
#set($foo = 'foo')
#set($bar = 'bar')
#test( $bar, $foo )
{{code}}
The expected result would be {{code}}bar foo{{code}}, but since 2.0 we get the
incorrect result {{code}}bar bar{{code}}, as if the first inner
{{code}}$foo{{code}} macro argument was overwritting the second argument
evaluation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-904) Add a flag for better backward compatibility with null macro arguments
[
https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17021252#comment-17021252
]
Claude Brisson commented on VELOCITY-904:
-
Yes, very much. I'll reproduce it and move it to a new issue if confirmed.
> Add a flag for better backward compatibility with null macro arguments
> --
>
> Key: VELOCITY-904
> URL: https://issues.apache.org/jira/browse/VELOCITY-904
> Project: Velocity
> Issue Type: Improvement
> Components: Engine
>Affects Versions: 2.0
>Reporter: Claude Brisson
>Assignee: Claude Brisson
>Priority: Minor
> Fix For: 2.2
>
>
> See [this
> comment|https://issues.apache.org/jira/browse/VELOCITY-542?focusedCommentId=16621819=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16621819]
> :
> {code}
> #macro(testmacro $parameter)
> $parameter
> #end
> #testmacro($return)
> {code}
> bq. which used to print "$return" (when $return is null or undefined) and we
> now get "$parameter".
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-904) Add a flag for better backward compatibility with null macro arguments
[
https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17019570#comment-17019570
]
Claude Brisson commented on VELOCITY-904:
-
But maybe I misunderstood your use case. You'll have to be more explicit, then.
What is defined beforehand and what is not? Which object does have a {{name}}
property?
> Add a flag for better backward compatibility with null macro arguments
> --
>
> Key: VELOCITY-904
> URL: https://issues.apache.org/jira/browse/VELOCITY-904
> Project: Velocity
> Issue Type: Improvement
> Components: Engine
>Affects Versions: 2.0
>Reporter: Claude Brisson
>Assignee: Claude Brisson
>Priority: Minor
> Fix For: 2.2
>
>
> See [this
> comment|https://issues.apache.org/jira/browse/VELOCITY-542?focusedCommentId=16621819=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16621819]
> :
> {code}
> #macro(testmacro $parameter)
> $parameter
> #end
> #testmacro($return)
> {code}
> bq. which used to print "$return" (when $return is null or undefined) and we
> now get "$parameter".
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-904) Add a flag for better backward compatibility with null macro arguments
[
https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17019556#comment-17019556
]
Claude Brisson commented on VELOCITY-904:
-
Yes. It means that if {{$test.name}} is null in the global context, the macro
will receive null as a value for the {{$name}} argument.
It means that you cannot rely on arguments being expressions of previous macro
argument names.
With a little distance, you will concede that such constructs are really a bad
practice: it means that the calling code uses names which are defined *inside*
the macro. Binding the calling code to the inner macro names means that you
wouldn't be able to rename macro arguments names without breaking calling code.
> Add a flag for better backward compatibility with null macro arguments
> --
>
> Key: VELOCITY-904
> URL: https://issues.apache.org/jira/browse/VELOCITY-904
> Project: Velocity
> Issue Type: Improvement
> Components: Engine
>Affects Versions: 2.0
>Reporter: Claude Brisson
>Assignee: Claude Brisson
>Priority: Minor
> Fix For: 2.2
>
>
> See [this
> comment|https://issues.apache.org/jira/browse/VELOCITY-542?focusedCommentId=16621819=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16621819]
> :
> {code}
> #macro(testmacro $parameter)
> $parameter
> #end
> #testmacro($return)
> {code}
> bq. which used to print "$return" (when $return is null or undefined) and we
> now get "$parameter".
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-904) Add a flag for better backward compatibility with null macro arguments
[
https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17019543#comment-17019543
]
Claude Brisson commented on VELOCITY-904:
-
2.x macros are more like functions than macros. Especially, the current
documentation is wrong on this subject and needs to be updated. It's not that
the `$test` argument shadows `$test.name`, it's that `$test.name` is evaluated
beforehand.
> Add a flag for better backward compatibility with null macro arguments
> --
>
> Key: VELOCITY-904
> URL: https://issues.apache.org/jira/browse/VELOCITY-904
> Project: Velocity
> Issue Type: Improvement
> Components: Engine
>Affects Versions: 2.0
>Reporter: Claude Brisson
>Assignee: Claude Brisson
>Priority: Minor
> Fix For: 2.2
>
>
> See [this
> comment|https://issues.apache.org/jira/browse/VELOCITY-542?focusedCommentId=16621819=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16621819]
> :
> {code}
> #macro(testmacro $parameter)
> $parameter
> #end
> #testmacro($return)
> {code}
> bq. which used to print "$return" (when $return is null or undefined) and we
> now get "$parameter".
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-924) Bad cache handling for java.lang.Class methods
[
https://issues.apache.org/jira/browse/VELOCITY-924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17011870#comment-17011870
]
Claude Brisson commented on VELOCITY-924:
-
Yes, the class must be public.
> Bad cache handling for java.lang.Class methods
> --
>
> Key: VELOCITY-924
> URL: https://issues.apache.org/jira/browse/VELOCITY-924
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.2
>Reporter: Thomas Mortagne
>Assignee: Claude Brisson
>Priority: Blocker
> Labels: regression
> Fix For: 2.2
>
>
> Requirement:
> A binding $var containing an object which class (org.xwiki.MyClass)
> implementing a {{String getName()}} method.
> The following code:
> {code}
> $var.class.getName()
> $var.getName()
> {code}
> fail with:
> {noformat}
> Caused by: org.apache.velocity.exception.MethodInvocationException:
> Invocation of method 'getName' in class org.xwiki.MyClass threw exception
> java.lang.IllegalArgumentException: object is not an instance of declaring
> class at mytemplaye[line 1, column 26]
> at
> org.apache.velocity.runtime.parser.node.ASTMethod.handleInvocationException(ASTMethod.java:306)
> at
> org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:239)
> at
> org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:369)
> at
> org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:490)
> at
> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:423)
> at org.apache.velocity.Template.merge(Template.java:358)
> at org.apache.velocity.Template.merge(Template.java:262)
> at
> org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:271)
> ... 69 more
> Caused by: java.lang.IllegalArgumentException: object is not an instance of
> declaring class
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:565)
> at
> org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:548)
> at
> org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:219)
> ... 75 more
> {noformat}
> The reason is that ClassUtils.getMethod cache does not make any difference
> between an instance of Class and and instance of
> org.xwiki.MyClass so when ASTMethod#execute ask for the second getName() it
> end up with Class#getName() instead of MyClass#getName().
> Was working fine in 1.7.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
