[jira] [Assigned] (VELTOOLS-206) Upgrade to Velocity Engine 2.4.2
[ https://issues.apache.org/jira/browse/VELTOOLS-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reassigned VELTOOLS-206: --- Assignee: (was: Michael Osipov) > 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 >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] [Closed] (VELOCITY-977) Upgrade Java Compiler Compiler to Version 7.0.13
[ https://issues.apache.org/jira/browse/VELOCITY-977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed VELOCITY-977. --- Resolution: Fixed Fixed with [86cfcf41105f8a25db11ca6483e33c20fc0804d9|https://gitbox.apache.org/repos/asf?p=velocity-engine.git=commit=86cfcf41105f8a25db11ca6483e33c20fc0804d9]. > Upgrade Java Compiler Compiler to Version 7.0.13 > > > Key: VELOCITY-977 > URL: https://issues.apache.org/jira/browse/VELOCITY-977 > Project: Velocity > Issue Type: Improvement >Reporter: Sylwester Lachiewicz >Assignee: Michael Osipov >Priority: Minor > Fix For: 2.4.2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-977) Upgrade Java Compiler Compiler to Version 7.0.13
[ https://issues.apache.org/jira/browse/VELOCITY-977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated VELOCITY-977: Fix Version/s: 2.4.2 > Upgrade Java Compiler Compiler to Version 7.0.13 > > > Key: VELOCITY-977 > URL: https://issues.apache.org/jira/browse/VELOCITY-977 > Project: Velocity > Issue Type: Improvement >Reporter: Sylwester Lachiewicz >Assignee: Michael Osipov >Priority: Minor > Fix For: 2.4.2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Assigned] (VELOCITY-977) Upgrade Java Compiler Compiler to Version 7.0.13
[ https://issues.apache.org/jira/browse/VELOCITY-977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reassigned VELOCITY-977: --- Assignee: Michael Osipov > Upgrade Java Compiler Compiler to Version 7.0.13 > > > Key: VELOCITY-977 > URL: https://issues.apache.org/jira/browse/VELOCITY-977 > Project: Velocity > Issue Type: Improvement >Reporter: Sylwester Lachiewicz >Assignee: Michael Osipov >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELTOOLS-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=17823152#comment-17823152 ] Michael Osipov edited comment on VELTOOLS-206 at 3/4/24 12:39 PM: -- No, because that version should not appear more than once on the log: https://github.com/apache/velocity-engine/commits/master/. But you are right about the tags, I have dropped them. was (Author: michael-o): No, because that version should not appear more than once on the log: https://github.com/apache/velocity-engine/commits/master/. But you are right, I have dropped the tags. > 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] (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=17823152#comment-17823152 ] Michael Osipov commented on VELTOOLS-206: - No, because that version should not appear more than once on the log: https://github.com/apache/velocity-engine/commits/master/. But you are right, I have dropped the tags. > 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] [Updated] (VELTOOLS-206) Upgrade to Velocity Engine 2.4.2
[ https://issues.apache.org/jira/browse/VELTOOLS-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated VELTOOLS-206: Summary: Upgrade to Velocity Engine 2.4.2 (was: Upgrade to Velocity Engine 2.4.1) > 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-978) Project Loom/Jdk21 Support?
[ https://issues.apache.org/jira/browse/VELOCITY-978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17821038#comment-17821038 ] Michael Osipov commented on VELOCITY-978: - This one is better suited for the dev mailing list, but I am not aware of any plans. PRs are always welcome. > Project Loom/Jdk21 Support? > --- > > Key: VELOCITY-978 > URL: https://issues.apache.org/jira/browse/VELOCITY-978 > Project: Velocity > Issue Type: Wish > Components: Engine >Reporter: Patrick Barry >Priority: Major > > |We are currently performing prep work to leverage JDK 21's Virtual Threads, > StructuredTaskScope, and Scoped Values. While we update our own code base, > we wanted to also reach out to this community to understand what plans are > being made or work already done to update this library as well. For example, > we see this library uses synchronized methods and ThreadLocals. Will those be > replaced? Is there a version we can watch for that will be designated as > 'Project Loom/JDK 21 Fully Supported'? Appreciate any insight.| -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Created] (VELTOOLS-206) Upgrade to Velocity Engine 2.4.1
Michael Osipov created VELTOOLS-206: --- Summary: Upgrade to Velocity Engine 2.4.1 Key: VELTOOLS-206 URL: https://issues.apache.org/jira/browse/VELTOOLS-206 Project: Velocity Tools Issue Type: Task Reporter: Michael Osipov Assignee: Michael Osipov 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] [Updated] (VELOCITY-975) Unicode characters cause issues
[
https://issues.apache.org/jira/browse/VELOCITY-975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated VELOCITY-975:
Description:
Ran across some cases of processing files using velocity with some unicode
characters in it that caused some unexpected results. Is there anything that I
can do to prevent or mitigate this short of stripping out a set of bad
characters before i had the script off to velocity?
{noformat}
org.apache.velocity.exception.ParseErrorException: Lexical error,
Encountered: "\u00a0" (160), after : "" at *unset*[line 1, column 19]
at
org.apache.velocity.runtime.RuntimeInstance.evaluate(RuntimeInstance.java:1437)
at
org.apache.velocity.app.VelocityEngine.evaluate(VelocityEngine.java:239)
{noformat}
was:
Ran across some cases of processing files using velocity with some unicode
characters in it that caused some unexpected results. Is there anything that I
can do to prevent or mitigate this short of stripping out a set of bad
characters before i had the script off to velocity?
org.apache.velocity.exception.ParseErrorException: Lexical error,
Encountered: "\u00a0" (160), after : "" at *unset*[line 1, column 19]
at
org.apache.velocity.runtime.RuntimeInstance.evaluate(RuntimeInstance.java:1437)
at
org.apache.velocity.app.VelocityEngine.evaluate(VelocityEngine.java:239)
> Unicode characters cause issues
> ---
>
> Key: VELOCITY-975
> URL: https://issues.apache.org/jira/browse/VELOCITY-975
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Alex O'Ree
>Priority: Major
>
> Ran across some cases of processing files using velocity with some unicode
> characters in it that caused some unexpected results. Is there anything that
> I can do to prevent or mitigate this short of stripping out a set of bad
> characters before i had the script off to velocity?
>
> {noformat}
> org.apache.velocity.exception.ParseErrorException: Lexical error,
> Encountered: "\u00a0" (160), after : "" at *unset*[line 1, column 19]
> at
> org.apache.velocity.runtime.RuntimeInstance.evaluate(RuntimeInstance.java:1437)
> at
> org.apache.velocity.app.VelocityEngine.evaluate(VelocityEngine.java:239)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Closed] (VELTOOLS-205) Upgrade to Velocity Engine 2.4
[ https://issues.apache.org/jira/browse/VELTOOLS-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed VELTOOLS-205. --- Resolution: Fixed Fixed with [22a0b721f4f69c2a4f2270098074614baac45995|https://gitbox.apache.org/repos/asf?p=velocity-tools.git;a=commit;h=22a0b721f4f69c2a4f2270098074614baac45995]. > Upgrade to Velocity Engine 2.4 > -- > > Key: VELTOOLS-205 > URL: https://issues.apache.org/jira/browse/VELTOOLS-205 > Project: Velocity Tools > Issue Type: Task >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 3.2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Closed] (VELTOOLS-200) Current Velocity Tools View uses deprecated Velocity properties
[
https://issues.apache.org/jira/browse/VELTOOLS-200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed VELTOOLS-200.
---
Resolution: Fixed
Fixed with
[48d64f351cc5be66c0becec29d2c538e9bbd5e88|https://gitbox.apache.org/repos/asf?p=velocity-tools.git;a=commit;h=48d64f351cc5be66c0becec29d2c538e9bbd5e88].
> Current Velocity Tools View uses deprecated Velocity properties
>
>
> Key: VELTOOLS-200
> URL: https://issues.apache.org/jira/browse/VELTOOLS-200
> Project: Velocity Tools
> Issue Type: Bug
> Components: VelocityView
>Affects Versions: 3.1
>Reporter: Gernot Hueller
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.2
>
>
> when using current Velocity with current Velocity Tools View , I get the
> following error messages in the log:
> {{org.apache.velocity.deprecation - configuration key 'resource.loader' has
> been deprecated in favor of 'resource.loaders'}}
> {{org.apache.velocity.deprecation - configuration key
> 'webapp.resource.loader.class' has been deprecated in favor of
> 'resource.loader.webapp.class'}}
> {{org.apache.velocity.deprecation - configuration key
> 'string.resource.loader.class' has been deprecated in favor of
> 'resource.loader.string.class'}}
> {{org.apache.velocity.deprecation - configuration key
> 'runtime.introspector.uberspect' has been deprecated in favor of
> 'introspector.uberspect.class'}}
>
> OK so maybe the old property names are used to be compatible to old Velocity
> Engine versions, but the default is that we use current versions - so a
> "compatibility mode" should be made smarter than just continuing to use
> deprecated properties.
> my gradle includes:
> {{earlib group: 'org.apache.velocity', name: 'velocity-engine-core', version:
> '2.3'}}
> {{earlib group: 'org.apache.velocity.tools', name: 'velocity-tools-view',
> version: '3.1'}}
>
> This has also been mentioned in a recent stackoverflow thread
> https://stackoverflow.com/questions/73026164/velocity-warnings-about-deprecated-keys-that-i-dont-even-use
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Created] (VELTOOLS-205) Upgrade to Velocity Engine 2.4
Michael Osipov created VELTOOLS-205: --- Summary: Upgrade to Velocity Engine 2.4 Key: VELTOOLS-205 URL: https://issues.apache.org/jira/browse/VELTOOLS-205 Project: Velocity Tools Issue Type: Task Reporter: Michael Osipov Assignee: Michael Osipov Fix For: 3.2 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELTOOLS-200) Current Velocity Tools View uses deprecated Velocity properties
[
https://issues.apache.org/jira/browse/VELTOOLS-200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816341#comment-17816341
]
Michael Osipov commented on VELTOOLS-200:
-
Found it...
> Current Velocity Tools View uses deprecated Velocity properties
>
>
> Key: VELTOOLS-200
> URL: https://issues.apache.org/jira/browse/VELTOOLS-200
> Project: Velocity Tools
> Issue Type: Bug
> Components: VelocityView
>Affects Versions: 3.1
>Reporter: Gernot Hueller
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.2
>
>
> when using current Velocity with current Velocity Tools View , I get the
> following error messages in the log:
> {{org.apache.velocity.deprecation - configuration key 'resource.loader' has
> been deprecated in favor of 'resource.loaders'}}
> {{org.apache.velocity.deprecation - configuration key
> 'webapp.resource.loader.class' has been deprecated in favor of
> 'resource.loader.webapp.class'}}
> {{org.apache.velocity.deprecation - configuration key
> 'string.resource.loader.class' has been deprecated in favor of
> 'resource.loader.string.class'}}
> {{org.apache.velocity.deprecation - configuration key
> 'runtime.introspector.uberspect' has been deprecated in favor of
> 'introspector.uberspect.class'}}
>
> OK so maybe the old property names are used to be compatible to old Velocity
> Engine versions, but the default is that we use current versions - so a
> "compatibility mode" should be made smarter than just continuing to use
> deprecated properties.
> my gradle includes:
> {{earlib group: 'org.apache.velocity', name: 'velocity-engine-core', version:
> '2.3'}}
> {{earlib group: 'org.apache.velocity.tools', name: 'velocity-tools-view',
> version: '3.1'}}
>
> This has also been mentioned in a recent stackoverflow thread
> https://stackoverflow.com/questions/73026164/velocity-warnings-about-deprecated-keys-that-i-dont-even-use
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Assigned] (VELTOOLS-200) Current Velocity Tools View uses deprecated Velocity properties
[
https://issues.apache.org/jira/browse/VELTOOLS-200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned VELTOOLS-200:
---
Assignee: Michael Osipov
> Current Velocity Tools View uses deprecated Velocity properties
>
>
> Key: VELTOOLS-200
> URL: https://issues.apache.org/jira/browse/VELTOOLS-200
> Project: Velocity Tools
> Issue Type: Bug
> Components: VelocityView
>Affects Versions: 3.1
>Reporter: Gernot Hueller
>Assignee: Michael Osipov
>Priority: Minor
>
> when using current Velocity with current Velocity Tools View , I get the
> following error messages in the log:
> {{org.apache.velocity.deprecation - configuration key 'resource.loader' has
> been deprecated in favor of 'resource.loaders'}}
> {{org.apache.velocity.deprecation - configuration key
> 'webapp.resource.loader.class' has been deprecated in favor of
> 'resource.loader.webapp.class'}}
> {{org.apache.velocity.deprecation - configuration key
> 'string.resource.loader.class' has been deprecated in favor of
> 'resource.loader.string.class'}}
> {{org.apache.velocity.deprecation - configuration key
> 'runtime.introspector.uberspect' has been deprecated in favor of
> 'introspector.uberspect.class'}}
>
> OK so maybe the old property names are used to be compatible to old Velocity
> Engine versions, but the default is that we use current versions - so a
> "compatibility mode" should be made smarter than just continuing to use
> deprecated properties.
> my gradle includes:
> {{earlib group: 'org.apache.velocity', name: 'velocity-engine-core', version:
> '2.3'}}
> {{earlib group: 'org.apache.velocity.tools', name: 'velocity-tools-view',
> version: '3.1'}}
>
> This has also been mentioned in a recent stackoverflow thread
> https://stackoverflow.com/questions/73026164/velocity-warnings-about-deprecated-keys-that-i-dont-even-use
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELTOOLS-200) Current Velocity Tools View uses deprecated Velocity properties
[
https://issues.apache.org/jira/browse/VELTOOLS-200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated VELTOOLS-200:
Fix Version/s: 3.2
> Current Velocity Tools View uses deprecated Velocity properties
>
>
> Key: VELTOOLS-200
> URL: https://issues.apache.org/jira/browse/VELTOOLS-200
> Project: Velocity Tools
> Issue Type: Bug
> Components: VelocityView
>Affects Versions: 3.1
>Reporter: Gernot Hueller
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.2
>
>
> when using current Velocity with current Velocity Tools View , I get the
> following error messages in the log:
> {{org.apache.velocity.deprecation - configuration key 'resource.loader' has
> been deprecated in favor of 'resource.loaders'}}
> {{org.apache.velocity.deprecation - configuration key
> 'webapp.resource.loader.class' has been deprecated in favor of
> 'resource.loader.webapp.class'}}
> {{org.apache.velocity.deprecation - configuration key
> 'string.resource.loader.class' has been deprecated in favor of
> 'resource.loader.string.class'}}
> {{org.apache.velocity.deprecation - configuration key
> 'runtime.introspector.uberspect' has been deprecated in favor of
> 'introspector.uberspect.class'}}
>
> OK so maybe the old property names are used to be compatible to old Velocity
> Engine versions, but the default is that we use current versions - so a
> "compatibility mode" should be made smarter than just continuing to use
> deprecated properties.
> my gradle includes:
> {{earlib group: 'org.apache.velocity', name: 'velocity-engine-core', version:
> '2.3'}}
> {{earlib group: 'org.apache.velocity.tools', name: 'velocity-tools-view',
> version: '3.1'}}
>
> This has also been mentioned in a recent stackoverflow thread
> https://stackoverflow.com/questions/73026164/velocity-warnings-about-deprecated-keys-that-i-dont-even-use
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Assigned] (VELTOOLS-200) Current Velocity Tools View uses deprecated Velocity properties
[
https://issues.apache.org/jira/browse/VELTOOLS-200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned VELTOOLS-200:
---
Assignee: (was: Michael Osipov)
> Current Velocity Tools View uses deprecated Velocity properties
>
>
> Key: VELTOOLS-200
> URL: https://issues.apache.org/jira/browse/VELTOOLS-200
> Project: Velocity Tools
> Issue Type: Bug
> Components: VelocityView
>Affects Versions: 3.1
>Reporter: Gernot Hueller
>Priority: Minor
>
> when using current Velocity with current Velocity Tools View , I get the
> following error messages in the log:
> {{org.apache.velocity.deprecation - configuration key 'resource.loader' has
> been deprecated in favor of 'resource.loaders'}}
> {{org.apache.velocity.deprecation - configuration key
> 'webapp.resource.loader.class' has been deprecated in favor of
> 'resource.loader.webapp.class'}}
> {{org.apache.velocity.deprecation - configuration key
> 'string.resource.loader.class' has been deprecated in favor of
> 'resource.loader.string.class'}}
> {{org.apache.velocity.deprecation - configuration key
> 'runtime.introspector.uberspect' has been deprecated in favor of
> 'introspector.uberspect.class'}}
>
> OK so maybe the old property names are used to be compatible to old Velocity
> Engine versions, but the default is that we use current versions - so a
> "compatibility mode" should be made smarter than just continuing to use
> deprecated properties.
> my gradle includes:
> {{earlib group: 'org.apache.velocity', name: 'velocity-engine-core', version:
> '2.3'}}
> {{earlib group: 'org.apache.velocity.tools', name: 'velocity-tools-view',
> version: '3.1'}}
>
> This has also been mentioned in a recent stackoverflow thread
> https://stackoverflow.com/questions/73026164/velocity-warnings-about-deprecated-keys-that-i-dont-even-use
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELTOOLS-200) Current Velocity Tools View uses deprecated Velocity properties
[
https://issues.apache.org/jira/browse/VELTOOLS-200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated VELTOOLS-200:
Fix Version/s: (was: 3.2)
> Current Velocity Tools View uses deprecated Velocity properties
>
>
> Key: VELTOOLS-200
> URL: https://issues.apache.org/jira/browse/VELTOOLS-200
> Project: Velocity Tools
> Issue Type: Bug
> Components: VelocityView
>Affects Versions: 3.1
>Reporter: Gernot Hueller
>Assignee: Michael Osipov
>Priority: Minor
>
> when using current Velocity with current Velocity Tools View , I get the
> following error messages in the log:
> {{org.apache.velocity.deprecation - configuration key 'resource.loader' has
> been deprecated in favor of 'resource.loaders'}}
> {{org.apache.velocity.deprecation - configuration key
> 'webapp.resource.loader.class' has been deprecated in favor of
> 'resource.loader.webapp.class'}}
> {{org.apache.velocity.deprecation - configuration key
> 'string.resource.loader.class' has been deprecated in favor of
> 'resource.loader.string.class'}}
> {{org.apache.velocity.deprecation - configuration key
> 'runtime.introspector.uberspect' has been deprecated in favor of
> 'introspector.uberspect.class'}}
>
> OK so maybe the old property names are used to be compatible to old Velocity
> Engine versions, but the default is that we use current versions - so a
> "compatibility mode" should be made smarter than just continuing to use
> deprecated properties.
> my gradle includes:
> {{earlib group: 'org.apache.velocity', name: 'velocity-engine-core', version:
> '2.3'}}
> {{earlib group: 'org.apache.velocity.tools', name: 'velocity-tools-view',
> version: '3.1'}}
>
> This has also been mentioned in a recent stackoverflow thread
> https://stackoverflow.com/questions/73026164/velocity-warnings-about-deprecated-keys-that-i-dont-even-use
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELTOOLS-200) Current Velocity Tools View uses deprecated Velocity properties
[
https://issues.apache.org/jira/browse/VELTOOLS-200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated VELTOOLS-200:
Summary: Current Velocity Tools View uses deprecated Velocity properties
(was: Current Velocity Tools View use deprecated Velocity properties )
> Current Velocity Tools View uses deprecated Velocity properties
>
>
> Key: VELTOOLS-200
> URL: https://issues.apache.org/jira/browse/VELTOOLS-200
> Project: Velocity Tools
> Issue Type: Bug
> Components: VelocityView
>Affects Versions: 3.1
>Reporter: Gernot Hueller
>Priority: Minor
>
> when using current Velocity with current Velocity Tools View , I get the
> following error messages in the log:
> {{org.apache.velocity.deprecation - configuration key 'resource.loader' has
> been deprecated in favor of 'resource.loaders'}}
> {{org.apache.velocity.deprecation - configuration key
> 'webapp.resource.loader.class' has been deprecated in favor of
> 'resource.loader.webapp.class'}}
> {{org.apache.velocity.deprecation - configuration key
> 'string.resource.loader.class' has been deprecated in favor of
> 'resource.loader.string.class'}}
> {{org.apache.velocity.deprecation - configuration key
> 'runtime.introspector.uberspect' has been deprecated in favor of
> 'introspector.uberspect.class'}}
>
> OK so maybe the old property names are used to be compatible to old Velocity
> Engine versions, but the default is that we use current versions - so a
> "compatibility mode" should be made smarter than just continuing to use
> deprecated properties.
> my gradle includes:
> {{earlib group: 'org.apache.velocity', name: 'velocity-engine-core', version:
> '2.3'}}
> {{earlib group: 'org.apache.velocity.tools', name: 'velocity-tools-view',
> version: '3.1'}}
>
> This has also been mentioned in a recent stackoverflow thread
> https://stackoverflow.com/questions/73026164/velocity-warnings-about-deprecated-keys-that-i-dont-even-use
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELTOOLS-200) Current Velocity Tools View uses deprecated Velocity properties
[
https://issues.apache.org/jira/browse/VELTOOLS-200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated VELTOOLS-200:
Fix Version/s: 3.2
> Current Velocity Tools View uses deprecated Velocity properties
>
>
> Key: VELTOOLS-200
> URL: https://issues.apache.org/jira/browse/VELTOOLS-200
> Project: Velocity Tools
> Issue Type: Bug
> Components: VelocityView
>Affects Versions: 3.1
>Reporter: Gernot Hueller
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.2
>
>
> when using current Velocity with current Velocity Tools View , I get the
> following error messages in the log:
> {{org.apache.velocity.deprecation - configuration key 'resource.loader' has
> been deprecated in favor of 'resource.loaders'}}
> {{org.apache.velocity.deprecation - configuration key
> 'webapp.resource.loader.class' has been deprecated in favor of
> 'resource.loader.webapp.class'}}
> {{org.apache.velocity.deprecation - configuration key
> 'string.resource.loader.class' has been deprecated in favor of
> 'resource.loader.string.class'}}
> {{org.apache.velocity.deprecation - configuration key
> 'runtime.introspector.uberspect' has been deprecated in favor of
> 'introspector.uberspect.class'}}
>
> OK so maybe the old property names are used to be compatible to old Velocity
> Engine versions, but the default is that we use current versions - so a
> "compatibility mode" should be made smarter than just continuing to use
> deprecated properties.
> my gradle includes:
> {{earlib group: 'org.apache.velocity', name: 'velocity-engine-core', version:
> '2.3'}}
> {{earlib group: 'org.apache.velocity.tools', name: 'velocity-tools-view',
> version: '3.1'}}
>
> This has also been mentioned in a recent stackoverflow thread
> https://stackoverflow.com/questions/73026164/velocity-warnings-about-deprecated-keys-that-i-dont-even-use
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Assigned] (VELTOOLS-200) Current Velocity Tools View uses deprecated Velocity properties
[
https://issues.apache.org/jira/browse/VELTOOLS-200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned VELTOOLS-200:
---
Assignee: Michael Osipov
> Current Velocity Tools View uses deprecated Velocity properties
>
>
> Key: VELTOOLS-200
> URL: https://issues.apache.org/jira/browse/VELTOOLS-200
> Project: Velocity Tools
> Issue Type: Bug
> Components: VelocityView
>Affects Versions: 3.1
>Reporter: Gernot Hueller
>Assignee: Michael Osipov
>Priority: Minor
>
> when using current Velocity with current Velocity Tools View , I get the
> following error messages in the log:
> {{org.apache.velocity.deprecation - configuration key 'resource.loader' has
> been deprecated in favor of 'resource.loaders'}}
> {{org.apache.velocity.deprecation - configuration key
> 'webapp.resource.loader.class' has been deprecated in favor of
> 'resource.loader.webapp.class'}}
> {{org.apache.velocity.deprecation - configuration key
> 'string.resource.loader.class' has been deprecated in favor of
> 'resource.loader.string.class'}}
> {{org.apache.velocity.deprecation - configuration key
> 'runtime.introspector.uberspect' has been deprecated in favor of
> 'introspector.uberspect.class'}}
>
> OK so maybe the old property names are used to be compatible to old Velocity
> Engine versions, but the default is that we use current versions - so a
> "compatibility mode" should be made smarter than just continuing to use
> deprecated properties.
> my gradle includes:
> {{earlib group: 'org.apache.velocity', name: 'velocity-engine-core', version:
> '2.3'}}
> {{earlib group: 'org.apache.velocity.tools', name: 'velocity-tools-view',
> version: '3.1'}}
>
> This has also been mentioned in a recent stackoverflow thread
> https://stackoverflow.com/questions/73026164/velocity-warnings-about-deprecated-keys-that-i-dont-even-use
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Closed] (VELTOOLS-203) Upgrade to Parent 6
[ https://issues.apache.org/jira/browse/VELTOOLS-203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed VELTOOLS-203. --- Resolution: Fixed Fixed with [cd1b7aeb4f20d396fba5d3a0c6b7916017b2c515|https://gitbox.apache.org/repos/asf?p=velocity-tools.git;a=commit;h=cd1b7aeb4f20d396fba5d3a0c6b7916017b2c515]. > Upgrade to Parent 6 > --- > > Key: VELTOOLS-203 > URL: https://issues.apache.org/jira/browse/VELTOOLS-203 > Project: Velocity Tools > Issue Type: Task >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 3.2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Created] (VELTOOLS-203) Upgrade to Parent 6
Michael Osipov created VELTOOLS-203: --- Summary: Upgrade to Parent 6 Key: VELTOOLS-203 URL: https://issues.apache.org/jira/browse/VELTOOLS-203 Project: Velocity Tools Issue Type: Task Reporter: Michael Osipov Assignee: Michael Osipov Fix For: 3.2 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Closed] (VELOCITY-974) Use non-deprecated config property for resource loaders in VelocityEngineFactory
[ https://issues.apache.org/jira/browse/VELOCITY-974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed VELOCITY-974. --- Resolution: Fixed Fixed with [d5c52e90489e30fc009d2cc5853be69b498403ae|https://gitbox.apache.org/repos/asf?p=velocity-engine.git;a=commit;h=d5c52e90489e30fc009d2cc5853be69b498403ae]. > Use non-deprecated config property for resource loaders in > VelocityEngineFactory > > > Key: VELOCITY-974 > URL: https://issues.apache.org/jira/browse/VELOCITY-974 > Project: Velocity > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 2.4 > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Created] (VELOCITY-974) Use non-deprecated config property for resource loaders in VelocityEngineFactory
Michael Osipov created VELOCITY-974: --- Summary: Use non-deprecated config property for resource loaders in VelocityEngineFactory Key: VELOCITY-974 URL: https://issues.apache.org/jira/browse/VELOCITY-974 Project: Velocity Issue Type: Improvement Affects Versions: 2.3 Reporter: Michael Osipov Assignee: Michael Osipov Fix For: 2.4 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Created] (VELOCITY-973) Upgrade dependencies
Michael Osipov created VELOCITY-973: --- Summary: Upgrade dependencies Key: VELOCITY-973 URL: https://issues.apache.org/jira/browse/VELOCITY-973 Project: Velocity Issue Type: Task Reporter: Michael Osipov Assignee: Michael Osipov Fix For: 2.4 * Upgrade to SLF4J 1.7.36 * Upgrade to Commons Lang 3.14.0 * Upgrade to Spring Framework 5.3.31 * Upgrade to HSQLDB 2.7.2 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Closed] (VELOCITY-951) DataSourceResourceLoader: property datasource_url wrong
[
https://issues.apache.org/jira/browse/VELOCITY-951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed VELOCITY-951.
---
Resolution: Fixed
Fixed with
[660c1365f2bc4af6d50892d3b6a065d361dcbd96|https://gitbox.apache.org/repos/asf?p=velocity-engine.git;a=commit;h=660c1365f2bc4af6d50892d3b6a065d361dcbd96].
> DataSourceResourceLoader: property datasource_url wrong
> ---
>
> Key: VELOCITY-951
> URL: https://issues.apache.org/jira/browse/VELOCITY-951
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Andreas Sachs
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 2.4
>
>
> According to the javadoc it's
> resource.loader.ds.{*}resource.{*}datasource_url =
> java:comp/env/jdbc/Velocity
> resource.loader.ds.resource.table = tb_velocity_template
>
> But in the implementation "resource" is missing (only for datasource_url):
> dataSourceName = StringUtils.trim(configuration.getString("datasource_url"));
> tableName = StringUtils.trim(configuration.getString("resource.table"));
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Closed] (VELOCITY-972) Remove Commons IO
[ https://issues.apache.org/jira/browse/VELOCITY-972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed VELOCITY-972. --- Resolution: Fixed Fixed with [5b094c606a0e4fe2aa1ccf09aa20864a6dbc45a8|https://gitbox.apache.org/repos/asf?p=velocity-engine.git;a=commit;h=5b094c606a0e4fe2aa1ccf09aa20864a6dbc45a8]. > Remove Commons IO > - > > Key: VELOCITY-972 > URL: https://issues.apache.org/jira/browse/VELOCITY-972 > Project: Velocity > Issue Type: Task > Components: Build, Engine >Affects Versions: 2.3 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 2.4 > > > There are only a few spots where Commons IO is used. These can be removed for > the two reasons: > * Replace with NIO2 methods > * Take input as-is since behavior has never been part of the contract > (Javadoc) -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Closed] (VELOCITY-971) Upgrade to Parent 6
[ https://issues.apache.org/jira/browse/VELOCITY-971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed VELOCITY-971. --- Resolution: Fixed Fixed with [a61516e964a15413a1b53e4522da00454c7882f6|https://gitbox.apache.org/repos/asf?p=velocity-engine.git;a=commit;h=a61516e964a15413a1b53e4522da00454c7882f6]. > Upgrade to Parent 6 > --- > > Key: VELOCITY-971 > URL: https://issues.apache.org/jira/browse/VELOCITY-971 > Project: Velocity > Issue Type: Improvement > Components: Build >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 2.4 > > > Parent 6 gives us the ability to clean up a lot of duplicate stuff in our > POMs. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELTOOLS-200) Current Velocity Tools View use deprecated Velocity properties
[
https://issues.apache.org/jira/browse/VELTOOLS-200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17813987#comment-17813987
]
Michael Osipov commented on VELTOOLS-200:
-
I will happily accept PRs and merge them.
> Current Velocity Tools View use deprecated Velocity properties
> ---
>
> Key: VELTOOLS-200
> URL: https://issues.apache.org/jira/browse/VELTOOLS-200
> Project: Velocity Tools
> Issue Type: Bug
> Components: VelocityView
>Affects Versions: 3.1
>Reporter: Gernot Hueller
>Priority: Minor
>
> when using current Velocity with current Velocity Tools View , I get the
> following error messages in the log:
> {{org.apache.velocity.deprecation - configuration key 'resource.loader' has
> been deprecated in favor of 'resource.loaders'}}
> {{org.apache.velocity.deprecation - configuration key
> 'webapp.resource.loader.class' has been deprecated in favor of
> 'resource.loader.webapp.class'}}
> {{org.apache.velocity.deprecation - configuration key
> 'string.resource.loader.class' has been deprecated in favor of
> 'resource.loader.string.class'}}
> {{org.apache.velocity.deprecation - configuration key
> 'runtime.introspector.uberspect' has been deprecated in favor of
> 'introspector.uberspect.class'}}
>
> OK so maybe the old property names are used to be compatible to old Velocity
> Engine versions, but the default is that we use current versions - so a
> "compatibility mode" should be made smarter than just continuing to use
> deprecated properties.
> my gradle includes:
> {{earlib group: 'org.apache.velocity', name: 'velocity-engine-core', version:
> '2.3'}}
> {{earlib group: 'org.apache.velocity.tools', name: 'velocity-tools-view',
> version: '3.1'}}
>
> This has also been mentioned in a recent stackoverflow thread
> https://stackoverflow.com/questions/73026164/velocity-warnings-about-deprecated-keys-that-i-dont-even-use
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Assigned] (VELOCITY-951) DataSourceResourceLoader: property datasource_url wrong
[
https://issues.apache.org/jira/browse/VELOCITY-951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned VELOCITY-951:
---
Assignee: Michael Osipov
> DataSourceResourceLoader: property datasource_url wrong
> ---
>
> Key: VELOCITY-951
> URL: https://issues.apache.org/jira/browse/VELOCITY-951
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Andreas Sachs
>Assignee: Michael Osipov
>Priority: Minor
>
> According to the javadoc it's
> resource.loader.ds.{*}resource.{*}datasource_url =
> java:comp/env/jdbc/Velocity
> resource.loader.ds.resource.table = tb_velocity_template
>
> But in the implementation "resource" is missing (only for datasource_url):
> dataSourceName = StringUtils.trim(configuration.getString("datasource_url"));
> tableName = StringUtils.trim(configuration.getString("resource.table"));
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-951) DataSourceResourceLoader: property datasource_url wrong
[
https://issues.apache.org/jira/browse/VELOCITY-951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated VELOCITY-951:
Fix Version/s: 2.4
> DataSourceResourceLoader: property datasource_url wrong
> ---
>
> Key: VELOCITY-951
> URL: https://issues.apache.org/jira/browse/VELOCITY-951
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Andreas Sachs
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 2.4
>
>
> According to the javadoc it's
> resource.loader.ds.{*}resource.{*}datasource_url =
> java:comp/env/jdbc/Velocity
> resource.loader.ds.resource.table = tb_velocity_template
>
> But in the implementation "resource" is missing (only for datasource_url):
> dataSourceName = StringUtils.trim(configuration.getString("datasource_url"));
> tableName = StringUtils.trim(configuration.getString("resource.table"));
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Closed] (VELOCITY-941) 1.7.x backport for SecureUberspector should block methods on ClassLoader and subclasses
[ https://issues.apache.org/jira/browse/VELOCITY-941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed VELOCITY-941. --- Fix Version/s: (was: 1.7.x) Assignee: (was: William Glass-Husain) Resolution: Won't Fix I am boldy saying that no one of us will touch 1.x ever again. > 1.7.x backport for SecureUberspector should block methods on ClassLoader and > subclasses > --- > > Key: VELOCITY-941 > URL: https://issues.apache.org/jira/browse/VELOCITY-941 > Project: Velocity > Issue Type: Improvement >Reporter: Cesar Hernandez >Priority: Major > > This is a backport for [https://github.com/apache/velocity-engine/tree/1.7.x] > branch from the patch merged into master via: > https://issues.apache.org/jira/browse/VELOCITY-931 > > PR available: > [https://github.com/apache/velocity-engine/pull/21] > > The 1.7.x branch need also > [https://github.com/apache/velocity-engine/pull/22] to be able to compile, > test and build via ant. > > -- 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-950) Skipping empty lines
[ https://issues.apache.org/jira/browse/VELOCITY-950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed VELOCITY-950. --- Resolution: Information Provided As [~ch...@christopherschultz.net] noted, this is not a bug and a solution has been provided. > Skipping empty lines > > > Key: VELOCITY-950 > URL: https://issues.apache.org/jira/browse/VELOCITY-950 > Project: Velocity > Issue Type: Wish > Components: Engine >Reporter: Ivan Galkin >Priority: Major > > I need to convert text from Word to PDF using "if" (or others) construction > of Velocity. I need to get rid of empty lines. > Example: > In Word it looks like: > «#if(xxx == "true)»1«#end» > «#if(yyy == "true)»1«#end» > «#if(zzz == "true)»1«#end» > If yyy == false, xxx and zzz are true in PDF we will get: > 1 > > 1 > But I need get it without an empty line somehow: > 1 > 1 > Is it possible to do it with such functionality? -- 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-972) Remove Commons IO
Michael Osipov created VELOCITY-972: --- Summary: Remove Commons IO Key: VELOCITY-972 URL: https://issues.apache.org/jira/browse/VELOCITY-972 Project: Velocity Issue Type: Task Components: Build, Engine Affects Versions: 2.3 Reporter: Michael Osipov Assignee: Michael Osipov Fix For: 2.4 There are only a few spots where Commons IO is used. These can be removed for the two reasons: * Replace with NIO2 methods * Take input as-is since behavior has never been part of the contract (Javadoc) -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-970) velocity-engine-core contains commons-io Maven descriptor
[ https://issues.apache.org/jira/browse/VELOCITY-970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated VELOCITY-970: Fix Version/s: 2.4 > velocity-engine-core contains commons-io Maven descriptor > - > > Key: VELOCITY-970 > URL: https://issues.apache.org/jira/browse/VELOCITY-970 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.3 >Reporter: Thomas Mortagne >Assignee: Michael Osipov >Priority: Major > Fix For: 2.4 > > > commons-io is embedded in velocity-engine-core, which is OK from Java point > of view since its package is renamed (not causing any dependency problems). > The problem is that it contains the commons-io Maven descriptors at the > standard location (/META-INF/maven/commons-io/commons-io/), which is a > problem when you analyze JAR files to find what's in it because it ends up > being identified as a JAR exposing commons-io (which is not the case since > it's weaved). > Honestly, it feels very strange to embed commons-io in the first place given > that commons-lang for example is a transitive dependency, so I feel like the > simplest would just be to remove all the plumbing to embed and weave > commons-io and simply keep it as a regular transitive dependency. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Created] (VELOCITY-971) Upgrade to Parent 6
Michael Osipov created VELOCITY-971: --- Summary: Upgrade to Parent 6 Key: VELOCITY-971 URL: https://issues.apache.org/jira/browse/VELOCITY-971 Project: Velocity Issue Type: Improvement Components: Build Reporter: Michael Osipov Assignee: Michael Osipov Fix For: 2.4 Parent 6 gives us the ability to clean up a lot of duplicate stuff in our POMs. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Closed] (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
]
Michael Osipov closed VELOCITY-940.
---
> 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-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=17805736#comment-17805736 ] Michael Osipov commented on VELOCITY-970: - [~cbrisson], I think we can live without it. It's people's responsibility to provide reasonable values. I'd remove it for non-test and later review test as well. > velocity-engine-core contains commons-io Maven descriptor > - > > Key: VELOCITY-970 > URL: https://issues.apache.org/jira/browse/VELOCITY-970 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.3 >Reporter: Thomas Mortagne >Priority: Major > > commons-io is embedded in velocity-engine-core, which is OK from Java point > of view since its package is renamed (not causing any dependency problems). > The problem is that it contains the commons-io Maven descriptors at the > standard location (/META-INF/maven/commons-io/commons-io/), which is a > problem when you analyze JAR files to find what's in it because it ends up > being identified as a JAR exposing commons-io (which is not the case since > it's weaved). > Honestly, it feels very strange to embed commons-io in the first place given > that commons-lang for example is a transitive dependency, so I feel like the > simplest would just be to remove all the plumbing to embed and weave > commons-io and simply keep it as a regular transitive dependency. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (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=17805047#comment-17805047 ] Michael Osipov edited comment on VELTOOLS-202 at 1/10/24 10:12 AM: --- reasonable: You don't just rename the old module, you add a second one, but better before even writing a single line I'd discuss my PR idea. It is not me who needs to start the discussion, but he because he wants to change something, not me. was (Author: michael-o): reasonable: You don't just rename the old module, you add a second one, but better before even writing a single line I'd discuss my PR idea. It is not me who needs to start the discussion, but the he because he wants to change something, not me. > 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] [Comment Edited] (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=17805047#comment-17805047 ] Michael Osipov edited comment on VELTOOLS-202 at 1/10/24 10:07 AM: --- reasonable: You don't just rename the old module, you add a second one, but better before even writing a single line I'd discuss my PR idea. It is not me who needs to start the discussion, but the he because he wants to change something, not me. was (Author: michael-o): reasonable: You don't just rename the old module, you add a second one, but better before even writing a single line I'd discuss my PR idea. > 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-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=17805040#comment-17805040 ] Michael Osipov commented on VELTOOLS-202: - Why? If someone provides are reasonable patch, both can be supported. No issue, but don't forget: this is a volunteer project. We work on stuff we have time for and care about. That's it. > 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-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=17804988#comment-17804988 ] Michael Osipov commented on VELTOOLS-202: - Why? I don't want do the same twice for identical code. > 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-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=17804870#comment-17804870 ] Michael Osipov commented on VELTOOLS-202: - [~ghueller], are you subscribed? [~mgrigorov], this makes single release management impossible. > 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-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=17804753#comment-17804753 ] Michael Osipov commented on VELTOOLS-202: - [~ghueller], the usual way is to have *two* modules which serve old **and** new, not replacing the old with the new one because both are required for the years to come. The PR blindly updated, leaving others behind. > 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] [Moved] (VELTOOLS-202) VelocityViewServlet extending from jakarta.servlet instead of javax.servlet
[ https://issues.apache.org/jira/browse/VELTOOLS-202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov moved VELOCITY-942 to VELTOOLS-202: -- Component/s: VelocityView (was: Engine) Key: VELTOOLS-202 (was: VELOCITY-942) Project: Velocity Tools (was: Velocity) > VelocityViewServlet extending from jakarta.servlet instead of javax.servlet > --- > > Key: VELTOOLS-202 > URL: https://issues.apache.org/jira/browse/VELTOOLS-202 > Project: Velocity Tools > Issue Type: New Feature > Components: VelocityView >Reporter: David Ruiz de Azua >Priority: Trivial > > To whom may concern, > Currently VelocityViewServlet extends from javax rather than jakarta. > Due the cutover from Java to Jakarta, *is there any plan to make Apache > Velocity compatible with Servlet 5.0?* > Not sure if there are any plans to make the transition to Jakarta namespace > and if there is any ETA for it. > [https://jakarta.ee/specifications/servlet/5.0/apidocs/jakarta/servlet/http/httpservlet] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-965) Velocity 1.7 vs velocity 2.3: Getting thread synchronization issue
[
https://issues.apache.org/jira/browse/VELOCITY-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17725744#comment-17725744
]
Michael Osipov commented on VELOCITY-965:
-
This is open source, you can provide a PR to address the issue. Moreover, you
cannot expect anything since this is open source. If you want progress, do
something.
> Velocity 1.7 vs velocity 2.3: Getting thread synchronization issue
> --
>
> Key: VELOCITY-965
> URL: https://issues.apache.org/jira/browse/VELOCITY-965
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Amrit
>Priority: Major
>
> Recently we migrated from Velocity 1.7 to Velocity 2.3. We see the below
> error intermittently which is a possible thread synchronization issue with
> Velocity Engine. The resultset is getting closed while another thread is
> making use of it.
> {noformat}
> 2023-04-15 10:36:33.472 ERROR [org.apache.velocity.loader.ds]
> {344} - DataSourceResourceLoader: database problem while getting timestamp of
> 'xyz_abc':
> java.sql.SQLException: Closed Resultset: next
> at
> oracle.jdbc.driver.InsensitiveScrollableResultSet.ensureOpen(InsensitiveScrollableResultSet.java:109)
> ~[ojdbc8.jar:12.2.0.1.0]
> at
> oracle.jdbc.driver.InsensitiveScrollableResultSet.next(InsensitiveScrollableResultSet.java:398)
> ~[ojdbc8.jar:12.2.0.1.0]
> at
> weblogic.jdbc.wrapper.ResultSet_oracle_jdbc_driver_ForwardOnlyResultSet.next(Unknown
> Source) ~[CodeGenerator.class:12.2.1.3]
> at
> org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader.readLastModified(DataSourceResourceLoader.java:326)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader.getLastModified(DataSourceResourceLoader.java:240)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:446)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:346)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1677)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1656)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.app.VelocityEngine.getTemplate(VelocityEngine.java:314)
> ~[velocity-engine-core-2.3.jar:2.3]
> {noformat}
> Reference:
> https://stackoverflow.com/questions/2794167/is-resultset-thread-safe
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-965) Velocity 1.7 vs velocity 2.3: Getting thread synchronization issue
[
https://issues.apache.org/jira/browse/VELOCITY-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17713740#comment-17713740
]
Michael Osipov commented on VELOCITY-965:
-
I took a brief look at the class. Something looks fishy to me: The class is a
singleton, yet it shares the connection and both prepared statements outside of
the scope of {{public synchronized Reader getResourceReader()}}. This doesn't
feel right to me.
> Velocity 1.7 vs velocity 2.3: Getting thread synchronization issue
> --
>
> Key: VELOCITY-965
> URL: https://issues.apache.org/jira/browse/VELOCITY-965
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Amrit
>Priority: Major
>
> Recently we migrated from Velocity 1.7 to Velocity 2.3. We see the below
> error intermittently which is a possible thread synchronization issue with
> Velocity Engine. The resultset is getting closed while another thread is
> making use of it.
> {noformat}
> 2023-04-15 10:36:33.472 ERROR [org.apache.velocity.loader.ds]
> {344} - DataSourceResourceLoader: database problem while getting timestamp of
> 'xyz_abc':
> java.sql.SQLException: Closed Resultset: next
> at
> oracle.jdbc.driver.InsensitiveScrollableResultSet.ensureOpen(InsensitiveScrollableResultSet.java:109)
> ~[ojdbc8.jar:12.2.0.1.0]
> at
> oracle.jdbc.driver.InsensitiveScrollableResultSet.next(InsensitiveScrollableResultSet.java:398)
> ~[ojdbc8.jar:12.2.0.1.0]
> at
> weblogic.jdbc.wrapper.ResultSet_oracle_jdbc_driver_ForwardOnlyResultSet.next(Unknown
> Source) ~[CodeGenerator.class:12.2.1.3]
> at
> org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader.readLastModified(DataSourceResourceLoader.java:326)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader.getLastModified(DataSourceResourceLoader.java:240)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:446)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:346)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1677)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1656)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.app.VelocityEngine.getTemplate(VelocityEngine.java:314)
> ~[velocity-engine-core-2.3.jar:2.3]
> {noformat}
> Reference:
> https://stackoverflow.com/questions/2794167/is-resultset-thread-safe
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-965) Velocity 1.7 vs velocity 2.3: Getting thread synchronization issue
[
https://issues.apache.org/jira/browse/VELOCITY-965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated VELOCITY-965:
Description:
Recently we migrated from Velocity 1.7 to Velocity 2.3. We see the below error
intermittently which is a possible thread synchronization issue with Velocity
Engine. The resultset is getting closed while another thread is making use of
it.
{noformat}
2023-04-15 10:36:33.472 ERROR [org.apache.velocity.loader.ds] \{344} -
DataSourceResourceLoader: database problem while getting timestamp of
'xyz_abc':
java.sql.SQLException: Closed Resultset: next
at
oracle.jdbc.driver.InsensitiveScrollableResultSet.ensureOpen(InsensitiveScrollableResultSet.java:109)
~[ojdbc8.jar:12.2.0.1.0]
at
oracle.jdbc.driver.InsensitiveScrollableResultSet.next(InsensitiveScrollableResultSet.java:398)
~[ojdbc8.jar:12.2.0.1.0]
at
weblogic.jdbc.wrapper.ResultSet_oracle_jdbc_driver_ForwardOnlyResultSet.next(Unknown
Source) ~[CodeGenerator.class:12.2.1.3]
at
org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader.readLastModified(DataSourceResourceLoader.java:326)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader.getLastModified(DataSourceResourceLoader.java:240)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:446)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:346)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1677)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1656)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.app.VelocityEngine.getTemplate(VelocityEngine.java:314)
~[velocity-engine-core-2.3.jar:2.3]
{noformat}
Reference:
https://stackoverflow.com/questions/2794167/is-resultset-thread-safe
was:
Recently we migrated from Velocity 1.7 to Velocity 2.3. We see the below error
intermittently which is a possible thread synchronization issue with Velocity
Engine. The resultset is getting closed while another thread is making use of
it.
2023-04-15 10:36:33.472 ERROR [org.apache.velocity.loader.ds] \{344} -
DataSourceResourceLoader: database problem while getting timestamp of
'xyz_abc':
java.sql.SQLException: Closed Resultset: next
at
oracle.jdbc.driver.InsensitiveScrollableResultSet.ensureOpen(InsensitiveScrollableResultSet.java:109)
~[ojdbc8.jar:12.2.0.1.0]
at
oracle.jdbc.driver.InsensitiveScrollableResultSet.next(InsensitiveScrollableResultSet.java:398)
~[ojdbc8.jar:12.2.0.1.0]
at
weblogic.jdbc.wrapper.ResultSet_oracle_jdbc_driver_ForwardOnlyResultSet.next(Unknown
Source) ~[CodeGenerator.class:12.2.1.3]
at
org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader.readLastModified(DataSourceResourceLoader.java:326)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader.getLastModified(DataSourceResourceLoader.java:240)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:446)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:346)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1677)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1656)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.app.VelocityEngine.getTemplate(VelocityEngine.java:314)
~[velocity-engine-core-2.3.jar:2.3]
Reference:
https://stackoverflow.com/questions/2794167/is-resultset-thread-safe
> Velocity 1.7 vs velocity 2.3: Getting thread synchronization issue
> --
>
> Key: VELOCITY-965
> URL: https://issues.apache.org/jira/browse/VELOCITY-965
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Amrit
>Priority: Major
>
> Recently we migrated from Velocity 1.7 to Velocity 2.3. We see the below
> error intermittently which is a possible thread synchronization issue with
> Velocity Engine. The resultset is getting closed while another thread is
> making use of it.
> {noformat}
> 2023-04-15 10:36:33.472 ERROR [org.apache.velocity.loader.ds] \{344} -
> DataSourceResourceLoader: database problem while getting timestamp of
> 'xyz_abc':
> java.sql.SQLException:
[jira] [Updated] (VELOCITY-965) Velocity 1.7 vs velocity 2.3: Getting thread synchronization issue
[
https://issues.apache.org/jira/browse/VELOCITY-965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated VELOCITY-965:
Description:
Recently we migrated from Velocity 1.7 to Velocity 2.3. We see the below error
intermittently which is a possible thread synchronization issue with Velocity
Engine. The resultset is getting closed while another thread is making use of
it.
{noformat}
2023-04-15 10:36:33.472 ERROR [org.apache.velocity.loader.ds]
{344} - DataSourceResourceLoader: database problem while getting timestamp of
'xyz_abc':
java.sql.SQLException: Closed Resultset: next
at
oracle.jdbc.driver.InsensitiveScrollableResultSet.ensureOpen(InsensitiveScrollableResultSet.java:109)
~[ojdbc8.jar:12.2.0.1.0]
at
oracle.jdbc.driver.InsensitiveScrollableResultSet.next(InsensitiveScrollableResultSet.java:398)
~[ojdbc8.jar:12.2.0.1.0]
at
weblogic.jdbc.wrapper.ResultSet_oracle_jdbc_driver_ForwardOnlyResultSet.next(Unknown
Source) ~[CodeGenerator.class:12.2.1.3]
at
org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader.readLastModified(DataSourceResourceLoader.java:326)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader.getLastModified(DataSourceResourceLoader.java:240)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:446)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:346)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1677)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1656)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.app.VelocityEngine.getTemplate(VelocityEngine.java:314)
~[velocity-engine-core-2.3.jar:2.3]
{noformat}
Reference:
https://stackoverflow.com/questions/2794167/is-resultset-thread-safe
was:
Recently we migrated from Velocity 1.7 to Velocity 2.3. We see the below error
intermittently which is a possible thread synchronization issue with Velocity
Engine. The resultset is getting closed while another thread is making use of
it.
{noformat}
2023-04-15 10:36:33.472 ERROR [org.apache.velocity.loader.ds] \{344} -
DataSourceResourceLoader: database problem while getting timestamp of
'xyz_abc':
java.sql.SQLException: Closed Resultset: next
at
oracle.jdbc.driver.InsensitiveScrollableResultSet.ensureOpen(InsensitiveScrollableResultSet.java:109)
~[ojdbc8.jar:12.2.0.1.0]
at
oracle.jdbc.driver.InsensitiveScrollableResultSet.next(InsensitiveScrollableResultSet.java:398)
~[ojdbc8.jar:12.2.0.1.0]
at
weblogic.jdbc.wrapper.ResultSet_oracle_jdbc_driver_ForwardOnlyResultSet.next(Unknown
Source) ~[CodeGenerator.class:12.2.1.3]
at
org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader.readLastModified(DataSourceResourceLoader.java:326)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader.getLastModified(DataSourceResourceLoader.java:240)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:446)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:346)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1677)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1656)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.app.VelocityEngine.getTemplate(VelocityEngine.java:314)
~[velocity-engine-core-2.3.jar:2.3]
{noformat}
Reference:
https://stackoverflow.com/questions/2794167/is-resultset-thread-safe
> Velocity 1.7 vs velocity 2.3: Getting thread synchronization issue
> --
>
> Key: VELOCITY-965
> URL: https://issues.apache.org/jira/browse/VELOCITY-965
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Amrit
>Priority: Major
>
> Recently we migrated from Velocity 1.7 to Velocity 2.3. We see the below
> error intermittently which is a possible thread synchronization issue with
> Velocity Engine. The resultset is getting closed while another thread is
> making use of it.
> {noformat}
> 2023-04-15 10:36:33.472 ERROR [org.apache.velocity.loader.ds]
> {344} - DataSourceResourceLoader: database problem while getting timestamp of
> 'xyz_abc':
>
[jira] [Assigned] (VELTOOLS-201) Document $esc.unicode() in Javadoc and page listing
[
https://issues.apache.org/jira/browse/VELTOOLS-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned VELTOOLS-201:
---
Assignee: (was: Michael Osipov)
> Document $esc.unicode() in Javadoc and page listing
> ---
>
> Key: VELTOOLS-201
> URL: https://issues.apache.org/jira/browse/VELTOOLS-201
> Project: Velocity Tools
> Issue Type: Task
> Components: GenericTools
>Affects Versions: 3.1
>Reporter: Michael Osipov
>Priority: Major
>
> No example for {{$esc.unicode()}} is provided here:
> https://velocity.apache.org/tools/3.1/apidocs/org/apache/velocity/tools/generic/EscapeTool.html
> nor is it mentioned here:
> https://velocity.apache.org/tools/3.1/tools-summary.html#EscapeTool
> Took me some time to find out have I can type in {{\u}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Created] (VELTOOLS-201) Document $esc.unicode() in Javadoc and page listing
Michael Osipov created VELTOOLS-201:
---
Summary: Document $esc.unicode() in Javadoc and page listing
Key: VELTOOLS-201
URL: https://issues.apache.org/jira/browse/VELTOOLS-201
Project: Velocity Tools
Issue Type: Task
Components: GenericTools
Affects Versions: 3.1
Reporter: Michael Osipov
Assignee: Michael Osipov
No example for {{$esc.unicode()}} is provided here:
https://velocity.apache.org/tools/3.1/apidocs/org/apache/velocity/tools/generic/EscapeTool.html
nor is it mentioned here:
https://velocity.apache.org/tools/3.1/tools-summary.html#EscapeTool
Took me some time to find out have I can type in {{\u}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [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=17705046#comment-17705046 ] Michael Osipov commented on VELOCITY-963: - Unless there is a bug or documentation deficit, this issue should be closed since breaking changes are OK for a major version. > Incompatible API changes in 2.x > --- > > Key: VELOCITY-963 > URL: https://issues.apache.org/jira/browse/VELOCITY-963 > Project: Velocity > Issue Type: Bug > Components: Documentation >Affects Versions: 2.0, 2.1, 2.2, 2.3 >Reporter: Éamonn McManus >Priority: Minor > > I recently tried porting a large amount of Velocity client code from 1.7 to > 2.3 and discovered a number of incompatible API changes. Some of these were > probably unavoidable but at least one could be fixed to ease this kind of > migration. > * The three RuntimeInstance.parse methods from 1.7 were replaced by a single > RuntimeInstance.parse(Reader, Template) method. I found that I could work > around this by changing this: > SimpleNode node = runtimeInstance.parse(reader, resourceName); > to this: > Template template = new Template(); > template.setName(resourceName); > SimpleNode node = runtimeInstance.parse(reader, template); > But it would be convenient for people migrating if the old overloads were > restored. (This might not be the best way to parse a template, but it was > certainly quite widely used in the code I was porting.) > * VelocityContext(Map) becomes VelocityContext(Map). Some of > the code was passing a Map or a Map. That would > work if the argument type were Map, but I don't think that would > be correct since I believe the Map can be updated by #set directives. So > perhaps document this more explicitly. > * This abstract method in ResourceLoader > InputStream getResourceStream(String source) > becomes > Reader getResourceReader(String source, String encoding) > I'm not sure there would have been a good way to allow subclasses of > ResourceLoader to continue to work without change, and this change _is_ > documented in the [migration > guide|https://velocity.apache.org/engine/2.0/upgrading.html#behavior-api-changes] > so there's probably nothing further to do here. > * Nearly all the methods in StringUtils have been deleted, and that's not > mentioned in the migration guide. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELTOOLS-197) xmlTool.find("./text()") (XPATH) not the same as xmlTool.getText () (METHOD) when & in text
[
https://issues.apache.org/jira/browse/VELTOOLS-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17704189#comment-17704189
]
Michael Osipov commented on VELTOOLS-197:
-
I absolutely agree on the trim. Violates POLA.
> xmlTool.find("./text()") (XPATH) not the same as xmlTool.getText () (METHOD)
> when & in text
> ---
>
> Key: VELTOOLS-197
> URL: https://issues.apache.org/jira/browse/VELTOOLS-197
> Project: Velocity Tools
> Issue Type: Bug
> Components: GenericTools
>Affects Versions: 3.1
>Reporter: steven van vlierberghe
>Priority: Major
>
> #foreach ($item2 in $xmlf1.find("/input/rep/x"))
> xpath: ${item2.find("./text()")} xml: $item2.getText()
> #end
> with $xmlf1 an XmlTool instance initialized on the following inputfile:
> {code:java}
>
>
> RR
> RB
>
>
> {code}
> using VeloctityTools-XmlTool 2.0 : find("./text()") returns same as
> getText() for an xmlTool instance (and complying with the expectation)
> {code:java}
> xpath: R xml: R
> xpath: R xml: R
> {code}
> However, using XmlTool 3.1, the xpath construct does not return the same as
> the getText,
> so the xpath does not comply with expectation
> {code:java}
> xpath: RR xml: R
> xpath: RB xml: R
> {code}
>
> PS:
> it can be solved in 3.1, by replacing $item2.find("./text()") by
> $item2.find("./text()").node().getNodeValue()
> BUT
> this really requires to adapt the script
> the actual problem is that I give support in our software to users for
> running their own Velocity scripts in our software.
> In the next version of our software, we upgraded Velocity + VelocityTools to
> 3.1
> and as a consequence, scripts of the users might break;
> meaning, this regression issue will impose our users to have to adapt their
> scripts that are used in production
> and for sure, they will not be happy having to do so
>
> PS2: also have the impression that plainly rendering $item2.find("./text()")
> as String also looses leading and trailing white space
>
> PS: the actual reason for upgrading VelocityTools (2.0 > 3.1) is that
> VeraCode flags the 2.0-related velocity libraries having vulnerabilities (and
> also dependent libraries like common- beanutils); these vulnerabilities have
> been solved in 3.1.
> Because there are (to us important) regression issues with upgrading the
> velocity stuff, we cannot upgrade and therefor remain stuck with flagged
> vulnerabilities in our software.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELTOOLS-200) Current Velocity Tools View use deprecated Velocity properties
[
https://issues.apache.org/jira/browse/VELTOOLS-200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated VELTOOLS-200:
Summary: Current Velocity Tools View use deprecated Velocity properties
(was: current Velocity Tools use deprecated Velocity properties )
> Current Velocity Tools View use deprecated Velocity properties
> ---
>
> Key: VELTOOLS-200
> URL: https://issues.apache.org/jira/browse/VELTOOLS-200
> Project: Velocity Tools
> Issue Type: Bug
> Components: VelocityView
>Affects Versions: 3.1
>Reporter: Gernot Hueller
>Priority: Minor
>
> when using current Velocity with current Velocity Tools View , I get the
> following error messages in the log:
> {{org.apache.velocity.deprecation - configuration key 'resource.loader' has
> been deprecated in favor of 'resource.loaders'}}
> {{org.apache.velocity.deprecation - configuration key
> 'webapp.resource.loader.class' has been deprecated in favor of
> 'resource.loader.webapp.class'}}
> {{org.apache.velocity.deprecation - configuration key
> 'string.resource.loader.class' has been deprecated in favor of
> 'resource.loader.string.class'}}
> {{org.apache.velocity.deprecation - configuration key
> 'runtime.introspector.uberspect' has been deprecated in favor of
> 'introspector.uberspect.class'}}
>
> OK so maybe the old property names are used to be compatible to old Velocity
> Engine versions, but the default is that we use current versions - so a
> "compatibility mode" should be made smarter than just continuing to use
> deprecated properties.
> my gradle includes:
> {{earlib group: 'org.apache.velocity', name: 'velocity-engine-core', version:
> '2.3'}}
> {{earlib group: 'org.apache.velocity.tools', name: 'velocity-tools-view',
> version: '3.1'}}
>
> This has also been mentioned in a recent stackoverflow thread
> https://stackoverflow.com/questions/73026164/velocity-warnings-about-deprecated-keys-that-i-dont-even-use
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [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=17631233#comment-17631233
]
Michael Osipov commented on VELOCITY-960:
-
Merci, Claude.
> Documentation inconsistency for use of hypens on identifiers
> -
>
> Key: VELOCITY-960
> URL: https://issues.apache.org/jira/browse/VELOCITY-960
> Project: Velocity
> Issue Type: Bug
>Reporter: Cesar Alvernaz
>Assignee: Claude Brisson
>Priority: Major
> Labels: doc
> Fix For: 2.3
>
>
> Regarding the use of hypens on identifiers, the documentation doesn't look
> consistent. Which one is recommended?
> [Here|https://velocity.apache.org/engine/2.3/configuration.html] states the
> following:
> *{{parser.allow_hyphen_in_identifiers = false}}*
> {quote}This is a backward compatibility option, false by default, which
> allows the '{*}{{-}}{*}' character inside variable identifiers (available
> since 2.1). If enabled, be warned that you will have to surround the
> mathematical minus sign with spaces for it to be correctly interpreted.
> {quote}
>
> But [here|https://velocity.apache.org/engine/2.3/vtl-reference.html], the
> configuration is different:
> {quote}{{If the *parser.allows.dash.identifiers*}} configuration value is set
> to true, then the *-* dash is also allowed in identifiers (and must be
> surrounded by spaces to be interpreted as an arithmetic minus operator).}}
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-960) Documentation inconsistency for use of hypens on identifiers
[
https://issues.apache.org/jira/browse/VELOCITY-960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17631027#comment-17631027
]
Michael Osipov edited comment on VELOCITY-960 at 11/9/22 12:01 PM:
---
The "parser.allows.dash.identifiers" mention is a reference to a long
disappeared name for this property.
The property name is "parser.allow_hyphen_in_identifiers", and it's a hyphen,
we're all good.
[~calvernaz] Thanks for catching this documentation glitch!
was (Author: claude):
The "parser.allows.dash.identifiers" mention is a reference to a long
disappeared name for this property.
The property name is "parser.allow_hyphen_in_identifiers", and it's a hyphen,
we're all good.
[~calvernaz] Thanks for catching this documentation glinche!
> Documentation inconsistency for use of hypens on identifiers
> -
>
> Key: VELOCITY-960
> URL: https://issues.apache.org/jira/browse/VELOCITY-960
> Project: Velocity
> Issue Type: Bug
>Reporter: Cesar Alvernaz
>Priority: Major
> Labels: doc
>
> Regarding the use of hypens on identifiers, the documentation doesn't look
> consistent. Which one is recommended?
> [Here|https://velocity.apache.org/engine/2.3/configuration.html] states the
> following:
> *{{parser.allow_hyphen_in_identifiers = false}}*
> {quote}This is a backward compatibility option, false by default, which
> allows the '{*}{{-}}{*}' character inside variable identifiers (available
> since 2.1). If enabled, be warned that you will have to surround the
> mathematical minus sign with spaces for it to be correctly interpreted.
> {quote}
>
> But [here|https://velocity.apache.org/engine/2.3/vtl-reference.html], the
> configuration is different:
> {quote}{{If the *parser.allows.dash.identifiers*}} configuration value is set
> to true, then the *-* dash is also allowed in identifiers (and must be
> surrounded by spaces to be interpreted as an arithmetic minus operator).}}
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-960) Documentation inconsistency for use of hypens on identifiers
[
https://issues.apache.org/jira/browse/VELOCITY-960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630858#comment-17630858
]
Michael Osipov commented on VELOCITY-960:
-
I need to create a followup ticket. A dash is *not* a hyphen. That property
needs to be changed in the future.
> Documentation inconsistency for use of hypens on identifiers
> -
>
> Key: VELOCITY-960
> URL: https://issues.apache.org/jira/browse/VELOCITY-960
> Project: Velocity
> Issue Type: Bug
>Reporter: Cesar Alvernaz
>Priority: Major
> Labels: doc
>
> Regarding the use of hypens on identifiers, the documentation doesn't look
> consistent. Which one is recommended?
> [Here|https://velocity.apache.org/engine/2.3/configuration.html] states the
> following:
> *{{parser.allow_hyphen_in_identifiers = false}}*
> {quote}This is a backward compatibility option, false by default, which
> allows the '{*}{{-}}{*}' character inside variable identifiers (available
> since 2.1). If enabled, be warned that you will have to surround the
> mathematical minus sign with spaces for it to be correctly interpreted.
> {quote}
>
> But [here|https://velocity.apache.org/engine/2.3/vtl-reference.html], the
> configuration is different:
> {quote}{{If the *parser.allows.dash.identifiers*}} configuration value is set
> to true, then the *-* dash is also allowed in identifiers (and must be
> surrounded by spaces to be interpreted as an arithmetic minus operator).}}
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-960) Documentation inconsistency for use of hypens on identifiers
[
https://issues.apache.org/jira/browse/VELOCITY-960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated VELOCITY-960:
Summary: Documentation inconsistency for use of hypens on identifiers
(was: Documentation inconsistency for use of dashes on identifiers )
> Documentation inconsistency for use of hypens on identifiers
> -
>
> Key: VELOCITY-960
> URL: https://issues.apache.org/jira/browse/VELOCITY-960
> Project: Velocity
> Issue Type: Bug
>Reporter: Cesar Alvernaz
>Priority: Major
> Labels: doc
>
> Regarding the use of dashes on identifiers, the documentation doesn't look
> consistent. Which one is recommended?
> [Here|https://velocity.apache.org/engine/2.3/configuration.html] states the
> following:
> *{{parser.allow_hyphen_in_identifiers = false}}*
> {quote}This is a backward compatibility option, false by default, which
> allows the '{*}{{-}}{*}' character inside variable identifiers (available
> since 2.1). If enabled, be warned that you will have to surround the
> mathematical minus sign with spaces for it to be correctly interpreted.
> {quote}
>
> But [here|https://velocity.apache.org/engine/2.3/vtl-reference.html], the
> configuration is different:
> {quote}{{If the *parser.allows.dash.identifiers*}} configuration value is set
> to true, then the *-* dash is also allowed in identifiers (and must be
> surrounded by spaces to be interpreted as an arithmetic minus operator).}}
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-960) Documentation inconsistency for use of hypens on identifiers
[
https://issues.apache.org/jira/browse/VELOCITY-960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated VELOCITY-960:
Description:
Regarding the use of hypens on identifiers, the documentation doesn't look
consistent. Which one is recommended?
[Here|https://velocity.apache.org/engine/2.3/configuration.html] states the
following:
*{{parser.allow_hyphen_in_identifiers = false}}*
{quote}This is a backward compatibility option, false by default, which allows
the '{*}{{-}}{*}' character inside variable identifiers (available since 2.1).
If enabled, be warned that you will have to surround the mathematical minus
sign with spaces for it to be correctly interpreted.
{quote}
But [here|https://velocity.apache.org/engine/2.3/vtl-reference.html], the
configuration is different:
{quote}{{If the *parser.allows.dash.identifiers*}} configuration value is set
to true, then the *-* dash is also allowed in identifiers (and must be
surrounded by spaces to be interpreted as an arithmetic minus operator).}}
{quote}
was:
Regarding the use of dashes on identifiers, the documentation doesn't look
consistent. Which one is recommended?
[Here|https://velocity.apache.org/engine/2.3/configuration.html] states the
following:
*{{parser.allow_hyphen_in_identifiers = false}}*
{quote}This is a backward compatibility option, false by default, which allows
the '{*}{{-}}{*}' character inside variable identifiers (available since 2.1).
If enabled, be warned that you will have to surround the mathematical minus
sign with spaces for it to be correctly interpreted.
{quote}
But [here|https://velocity.apache.org/engine/2.3/vtl-reference.html], the
configuration is different:
{quote}{{If the *parser.allows.dash.identifiers*}} configuration value is set
to true, then the *-* dash is also allowed in identifiers (and must be
surrounded by spaces to be interpreted as an arithmetic minus operator).}}
{quote}
> Documentation inconsistency for use of hypens on identifiers
> -
>
> Key: VELOCITY-960
> URL: https://issues.apache.org/jira/browse/VELOCITY-960
> Project: Velocity
> Issue Type: Bug
>Reporter: Cesar Alvernaz
>Priority: Major
> Labels: doc
>
> Regarding the use of hypens on identifiers, the documentation doesn't look
> consistent. Which one is recommended?
> [Here|https://velocity.apache.org/engine/2.3/configuration.html] states the
> following:
> *{{parser.allow_hyphen_in_identifiers = false}}*
> {quote}This is a backward compatibility option, false by default, which
> allows the '{*}{{-}}{*}' character inside variable identifiers (available
> since 2.1). If enabled, be warned that you will have to surround the
> mathematical minus sign with spaces for it to be correctly interpreted.
> {quote}
>
> But [here|https://velocity.apache.org/engine/2.3/vtl-reference.html], the
> configuration is different:
> {quote}{{If the *parser.allows.dash.identifiers*}} configuration value is set
> to true, then the *-* dash is also allowed in identifiers (and must be
> surrounded by spaces to be interpreted as an arithmetic minus operator).}}
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELTOOLS-198) org.apache.velocity.tools.ConversionUtils#getNumberFormat(java.lang.String, java.util.Locale) is not thread safe for custom formats
[
https://issues.apache.org/jira/browse/VELTOOLS-198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630583#comment-17630583
]
Michael Osipov commented on VELTOOLS-198:
-
So basically we are talking about
{{org.apache.velocity.tools.generic.NumberTool.getNumberFormat(String,
Locale)]] and {{org.apache.velocity.tools.generic.NumberTool.format()}}? I
agree that the NFs require external synchronization.
> org.apache.velocity.tools.ConversionUtils#getNumberFormat(java.lang.String,
> java.util.Locale) is not thread safe for custom formats
> ---
>
> Key: VELTOOLS-198
> URL: https://issues.apache.org/jira/browse/VELTOOLS-198
> Project: Velocity Tools
> Issue Type: Bug
> Components: GenericTools
>Affects Versions: 3.1
>Reporter: Oscar Doral
>Priority: Major
> Labels: pull-request-available
>
> org.apache.velocity.tools.ConversionUtils holds a cache for custom formats so
> it can reuse formatters across different requests:
> {code:java}
> private static ConcurrentMap customFormatsCache = new
> ConcurrentHashMap(); {code}
> Problem is formatters don't use to be thread safe so if same formatter is
> used at the same time by two different threads we can get errors depending on
> race conditions.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELTOOLS-197) xmlTool.find("./text()") (XPATH) not the same as xmlTool.getText () (METHOD) when & in text
[
https://issues.apache.org/jira/browse/VELTOOLS-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17616394#comment-17616394
]
Michael Osipov commented on VELTOOLS-197:
-
Interesting, that seems odd!
> xmlTool.find("./text()") (XPATH) not the same as xmlTool.getText () (METHOD)
> when & in text
> ---
>
> Key: VELTOOLS-197
> URL: https://issues.apache.org/jira/browse/VELTOOLS-197
> Project: Velocity Tools
> Issue Type: Bug
> Components: GenericTools
>Affects Versions: 3.1
>Reporter: steven van vlierberghe
>Priority: Major
>
> #foreach ($item2 in $xmlf1.find("/input/rep/x"))
> xpath: ${item2.find("./text()")} xml: $item2.getText()
> #end
> with $xmlf1 an XmlTool instance initialized on the following inputfile:
> {code:java}
>
>
> RR
> RB
>
>
> {code}
> using VeloctityTools-XmlTool 2.0 : find("./text()") returns same as
> getText() for an xmlTool instance (and complying with the expectation)
> {code:java}
> xpath: R xml: R
> xpath: R xml: R
> {code}
> However, using XmlTool 3.1, the xpath construct does not return the same as
> the getText,
> so the xpath does not comply with expectation
> {code:java}
> xpath: RR xml: R
> xpath: RB xml: R
> {code}
>
> PS:
> it can be solved in 3.1, by replacing $item2.find("./text()") by
> $item2.find("./text()").node().getNodeValue()
> BUT
> this really requires to adapt the script
> the actual problem is that I give support in our software to users for
> running their own Velocity scripts in our software.
> In the next version of our software, we upgraded Velocity + VelocityTools to
> 3.1
> and as a consequence, scripts of the users might break;
> meaning, this regression issue will impose our users to have to adapt their
> scripts that are used in production
> and for sure, they will not be happy having to do so
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Closed] (VELOCITY-954) spring-velocity-support involve CVE-2022-22965
[ https://issues.apache.org/jira/browse/VELOCITY-954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed VELOCITY-954. --- > spring-velocity-support involve CVE-2022-22965 > --- > > Key: VELOCITY-954 > URL: https://issues.apache.org/jira/browse/VELOCITY-954 > Project: Velocity > Issue Type: Bug >Affects Versions: 2.3 >Reporter: zhaizeyu >Priority: Major > > spring-velocity-support 2.3 contains passive dependencies spring-beans 5.3.4 > spring-beans involve vulnerabilities CVE-2022-22965,need to upgrade component > to fix the vulnerability -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELTOOLS-195) ConversionTool is deprecated, but no alternative for toBoolean*() provided
[
https://issues.apache.org/jira/browse/VELTOOLS-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17570865#comment-17570865
]
Michael Osipov commented on VELTOOLS-195:
-
Fantastic, can't wait to make it happen with 3.2 and Doxia Sitetools.
> ConversionTool is deprecated, but no alternative for toBoolean*() provided
> --
>
> Key: VELTOOLS-195
> URL: https://issues.apache.org/jira/browse/VELTOOLS-195
> Project: Velocity Tools
> Issue Type: Bug
> Components: GenericTools
>Affects Versions: 3.1
>Reporter: Michael Osipov
>Assignee: Claude Brisson
>Priority: Major
> Fix For: 3.2
>
>
> The {{ConversionTool}} has been deprecated with multiple alternatives, but
> none for {{boolean}}. Thus, relying on {{toBoolean()}} will fail in the
> future. Provide a sane migration path.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELTOOLS-195) ConversionTool is deprecated, but no alternative for toBoolean*() provided
[
https://issues.apache.org/jira/browse/VELTOOLS-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17570751#comment-17570751
]
Michael Osipov commented on VELTOOLS-195:
-
[~cbrisson], can you give an advice? This is imporant to the next stack of the
entire Maven Site ecosystem.
> ConversionTool is deprecated, but no alternative for toBoolean*() provided
> --
>
> Key: VELTOOLS-195
> URL: https://issues.apache.org/jira/browse/VELTOOLS-195
> Project: Velocity Tools
> Issue Type: Bug
> Components: GenericTools
>Affects Versions: 3.1
>Reporter: Michael Osipov
>Priority: Major
>
> The {{ConversionTool}} has been deprecated with multiple alternatives, but
> non for {{boolean}}. Thus, relying on {{toBoolean()}} will fail in the
> future. Provide a sane migration path.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELTOOLS-195) ConversionTool is deprecated, but no alternative for toBoolean*() provided
[
https://issues.apache.org/jira/browse/VELTOOLS-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated VELTOOLS-195:
Description: The {{ConversionTool}} has been deprecated with multiple
alternatives, but none for {{boolean}}. Thus, relying on {{toBoolean()}} will
fail in the future. Provide a sane migration path. (was: The
{{ConversionTool}} has been deprecated with multiple alternatives, but non for
{{boolean}}. Thus, relying on {{toBoolean()}} will fail in the future. Provide
a sane migration path.)
> ConversionTool is deprecated, but no alternative for toBoolean*() provided
> --
>
> Key: VELTOOLS-195
> URL: https://issues.apache.org/jira/browse/VELTOOLS-195
> Project: Velocity Tools
> Issue Type: Bug
> Components: GenericTools
>Affects Versions: 3.1
>Reporter: Michael Osipov
>Priority: Major
>
> The {{ConversionTool}} has been deprecated with multiple alternatives, but
> none for {{boolean}}. Thus, relying on {{toBoolean()}} will fail in the
> future. Provide a sane migration path.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Closed] (VELOCITY-958) Template should be cloneable
[ https://issues.apache.org/jira/browse/VELOCITY-958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed VELOCITY-958. --- > Template should be cloneable > > > Key: VELOCITY-958 > URL: https://issues.apache.org/jira/browse/VELOCITY-958 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.3 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Minor > Fix For: 2.4 > > > Templates should be cloneable, the clone() method returning a template with a > deep clone of the AST tree. > It allows for dynamic transformations of the AST tree which don't affect the > original template. > One use case is the translation of ASTText nodes. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Closed] (VELOCITY-959) Ease subclassing of #parse and #include directives
[ https://issues.apache.org/jira/browse/VELOCITY-959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed VELOCITY-959. --- > Ease subclassing of #parse and #include directives > -- > > Key: VELOCITY-959 > URL: https://issues.apache.org/jira/browse/VELOCITY-959 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.3 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Minor > Fix For: 2.4 > > > The #include directive should expose a protected getResource() method and the > #parse directive a protected getTemplate() method so that it is easier to > customize their behavior in a user defined directive inheriting from them. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-957) Unexpected compare result
[
https://issues.apache.org/jira/browse/VELOCITY-957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17558409#comment-17558409
]
Michael Osipov commented on VELOCITY-957:
-
Interesting...we need to check the type coercion. Both should be string, thus
false.
> Unexpected compare result
> -
>
> Key: VELOCITY-957
> URL: https://issues.apache.org/jira/browse/VELOCITY-957
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Kai Bächle
>Priority: Major
>
> {code:java}
> #if('1' == '1.0')same#{else}different#end {code}
> has "same" as result using velocity 2.3 and "different" using 1.7
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Created] (VELTOOLS-195) ConversionTool is deprecated, but no alternative for toBoolean*() provided
Michael Osipov created VELTOOLS-195:
---
Summary: ConversionTool is deprecated, but no alternative for
toBoolean*() provided
Key: VELTOOLS-195
URL: https://issues.apache.org/jira/browse/VELTOOLS-195
Project: Velocity Tools
Issue Type: Bug
Components: GenericTools
Affects Versions: 3.1
Reporter: Michael Osipov
The {{ConversionTool}} has been deprecated with multiple alternatives, but non
for {{boolean}}. Thus, relying on {{toBoolean()}} will fail in the future.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELTOOLS-195) ConversionTool is deprecated, but no alternative for toBoolean*() provided
[
https://issues.apache.org/jira/browse/VELTOOLS-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated VELTOOLS-195:
Description: The {{ConversionTool}} has been deprecated with multiple
alternatives, but non for {{boolean}}. Thus, relying on {{toBoolean()}} will
fail in the future. Provide a sane migration path. (was: The
{{ConversionTool}} has been deprecated with multiple alternatives, but non for
{{boolean}}. Thus, relying on {{toBoolean()}} will fail in the future.)
> ConversionTool is deprecated, but no alternative for toBoolean*() provided
> --
>
> Key: VELTOOLS-195
> URL: https://issues.apache.org/jira/browse/VELTOOLS-195
> Project: Velocity Tools
> Issue Type: Bug
> Components: GenericTools
>Affects Versions: 3.1
>Reporter: Michael Osipov
>Priority: Major
>
> The {{ConversionTool}} has been deprecated with multiple alternatives, but
> non for {{boolean}}. Thus, relying on {{toBoolean()}} will fail in the
> future. Provide a sane migration path.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-956) velocity 1.7 vs velocity 2.3: evaluation of scripts with empty value is not backward compatible
[
https://issues.apache.org/jira/browse/VELOCITY-956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated VELOCITY-956:
Fix Version/s: (was: 2.3)
> velocity 1.7 vs velocity 2.3: evaluation of scripts with empty value is not
> backward compatible
> ---
>
> Key: VELOCITY-956
> URL: https://issues.apache.org/jira/browse/VELOCITY-956
> Project: Velocity
> Issue Type: Bug
> Components: Engine, Scripting
>Affects Versions: 2.3
>Reporter: ambika
>Priority: Major
>
> {*}Script{*}:
>
> "vLATE_GATE_IN_6":"#set( $inTimeZone =
> $date.getTimeZone().getTimeZone('Europe/Berlin') )\n\n#set( $outTimeZone =
> $date.getTimeZone().getTimeZone('Asia/Shanghai') )\n\n#set( $locale =
> $date.getLocale() )\n\n#set( $myDate =
> $convert.parseDate(${*}{lead.lateGateIn}{*},\"-MM-dd
> HH:mm\",$locale,$inTimeZone) )\n\n${date.format('-MM-dd hh:mm
> a',$myDate,$locale,$outTimeZone)} "
> {*}note{*}: lead.lateGateIn = "" in the values
> there are multiple other scripts vLATE_GATE_IN_5, vLATE_GATE_IN_4 but in the
> script vLATE_GATE_IN_4 , the values for convert.parseDate is given as below:
> $convert.parseDate("2022-04-22")
>
> {*}Issue{*}:
> Older version of velocity evaluates the script vLATE_GATE_IN_6 to:
> |Time):\\n\\n\\n\\n\\n2022-04-22 11:00 AM|
>
> Newer version of velocity evaluates the script vLATE_GATE_IN_6 to:
> | |Time):\\n\\n\\n\\n\\n${date.format('-MM-dd hh:mm
> a',$myDate,$locale,$outTimeZone)}| |
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-955) velocity 1.7 vs velocity 2.3 : the evaluation of if condition in script is different
[
https://issues.apache.org/jira/browse/VELOCITY-955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated VELOCITY-955:
Fix Version/s: (was: 2.3)
> velocity 1.7 vs velocity 2.3 : the evaluation of if condition in script is
> different
> -
>
> Key: VELOCITY-955
> URL: https://issues.apache.org/jira/browse/VELOCITY-955
> Project: Velocity
> Issue Type: Bug
> Components: Scripting
>Affects Versions: 2.3
>Reporter: ambika
>Priority: Major
>
> *script used :*
>
> Map variables = new HashMap<>();
> variables.put("key1", "value");
>
> Context context = velocityManager.getToolsContext(variables);
>
> String inString = "#set($value = \"key value false\")" +
> "#if(${key1} == 1 ||\"yes\" )" +
> " #set($value = \"**key value true**\")" +
> "#end\n${value}";
>
> inString = velocityManager.evaluate(context, "tag", inString);
> System.out.println(inString);
>
>
> Output:
>
> older version output : key value true
>
> newer version output : key value false
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-954) spring-velocity-support involve CVE-2022-22965
[ https://issues.apache.org/jira/browse/VELOCITY-954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524193#comment-17524193 ] Michael Osipov commented on VELOCITY-954: - You can easily override the version and you should. We can't race version for version. > spring-velocity-support involve CVE-2022-22965 > --- > > Key: VELOCITY-954 > URL: https://issues.apache.org/jira/browse/VELOCITY-954 > Project: Velocity > Issue Type: Bug >Affects Versions: 2.3 >Reporter: zhaizeyu >Priority: Major > > spring-velocity-support 2.3 contains passive dependencies spring-beans 5.3.4 > spring-beans involve vulnerabilities CVE-2022-22965,need to upgrade component > to fix the vulnerability -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-952) Velocity is calling the "wrong" method
[
https://issues.apache.org/jira/browse/VELOCITY-952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17504510#comment-17504510
]
Michael Osipov commented on VELOCITY-952:
-
Nice catch, I am clueless. Let's ask an JPMS expert: [~rfscholte], can you help?
> Velocity is calling the "wrong" method
> --
>
> Key: VELOCITY-952
> URL: https://issues.apache.org/jira/browse/VELOCITY-952
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Thomas Mortagne
>Priority: Major
>
> OK, the title is maybe a bit harsh, but it catches the eyes :)
> At XWiki we recently started testing on Java 17 to see if there is any
> problem which leaded us to add things like {{--add-opens
> java.base/java.util=ALL-UNNAMED}} but Velocity happen to be the source of
> another problem related to the new module world.
> When doing something like {{$datetool.timeZone.getOffset(0)}} ($datetool
> being the org.apache.velocity.tools.generic.DateTool) we get the following
> error:
> {noformat}
> ...
> Caused by: java.lang.IllegalAccessException: class
> org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl cannot
> access class sun.util.calendar.ZoneInfo (in module java.base) because module
> java.base does not export sun.util.calendar to unnamed module @7ca16adc
> at
> java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:392)
> at
> java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674)
> at java.base/java.lang.reflect.Method.invoke(Method.java:560)
> at
> org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:571)
> at
> org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:554)
> at
> org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:221)
> ... 199 more
> {noformat}
> The reason is that while the developer intent/expectation was to call
> "java.util.TimeZone#getOffset(0)" what Velocity really called from JVM point
> of view is "sun.util.calendar.ZoneInfo.getOffset(0)" directly.
> That's because Velocity is doing (I assume, since I did not check the exact
> code) the equivalent of:
> {{noformat}}
> java.util.TimeZone.getDefault().getClass().getMethod("getOffset",
> long.class).invoke(TimeZone.getDefault(), 0);
> {{noformat}}
> which is itself the equivalent of:
> {{noformat}}
> sun.util.calendar.ZoneInfo.class.getMethod("getOffset",
> long.class).invoke(TimeZone.getDefault(), 0);
> {{noformat}}
> I guess the only way to fix this would be to track down the lowest overridden
> Method (I agree, it might not always be easy to choose between two interfaces
> declaring a method with the same signature, but choosing the first one we
> find from the same hierarchy level is still better than nothing) and call
> that one instead. With the use case used as example in this issue, that would
> mean ending up doing the equivalent of:
> {{noformat}}
> java.util.TimeZone.class.getMethod("getOffset",
> long.class).invoke(TimeZone.getDefault(), 0);
> {{noformat}}
> which, from JVM point of view, is covered by the {{--add-opens
> java.base/java.util=ALL-UNNAMED}}.
> It would be a big change, but at least can't think of any retro-compatibility
> problem it might cause.
> One might be tempted to answer "just add {{--add-opens
> java.base/sun.util.calendar=ALL-UNNAMED}}" but it does not seem fair as this
> is not what the API that the script uses was exposing at all, you might need
> to document a different one for each JVM implementation (even if it's
> probably unlikely for this specific example) but more importantly you will
> potentially need quite a lot of those and will only discover it at runtime
> since it's not so easy to guess from an API in which you only know the public
> JVM classes since that's what you manipulate.
> I would be happy to work on this, but I wanted first ask what others think
> about this problem in general and the possible solutions I may have missed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-952) Velocity is calling the "wrong" method
[
https://issues.apache.org/jira/browse/VELOCITY-952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated VELOCITY-952:
Summary: Velocity is calling the "wrong" method (was: Velocity is calling
the "wrong" Method)
> Velocity is calling the "wrong" method
> --
>
> Key: VELOCITY-952
> URL: https://issues.apache.org/jira/browse/VELOCITY-952
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Thomas Mortagne
>Priority: Major
>
> OK, the title is maybe a bit harsh, but it catches the eyes :)
> At XWiki we recently started testing on Java 17 to see if there is any
> problem which leaded us to add things like {{--add-opens
> java.base/java.util=ALL-UNNAMED}} but Velocity happen to be the source of
> another problem related to the new module world.
> When doing something like {{$datetool.timeZone.getOffset(0)}} ($datetool
> being the org.apache.velocity.tools.generic.DateTool) we get the following
> error:
> {noformat}
> ...
> Caused by: java.lang.IllegalAccessException: class
> org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl cannot
> access class sun.util.calendar.ZoneInfo (in module java.base) because module
> java.base does not export sun.util.calendar to unnamed module @7ca16adc
> at
> java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:392)
> at
> java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674)
> at java.base/java.lang.reflect.Method.invoke(Method.java:560)
> at
> org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:571)
> at
> org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:554)
> at
> org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:221)
> ... 199 more
> {noformat}
> The reason is that while the developer intent/expectation was to call
> "java.util.TimeZone#getOffset(0)" what Velocity really called from JVM point
> of view is "sun.util.calendar.ZoneInfo.getOffset(0)" directly.
> That's because Velocity is doing (I assume, since I did not check the exact
> code) the equivalent of:
> {{noformat}}
> java.util.TimeZone.getDefault().getClass().getMethod("getOffset",
> long.class).invoke(TimeZone.getDefault(), 0);
> {{noformat}}
> which is itself the equivalent of:
> {{noformat}}
> sun.util.calendar.ZoneInfo.class.getMethod("getOffset",
> long.class).invoke(TimeZone.getDefault(), 0);
> {{noformat}}
> I guess the only way to fix this would be to track down the lowest overridden
> Method (I agree, it might not always be easy to choose between two interfaces
> declaring a method with the same signature, but choosing the first one we
> find from the same hierarchy level is still better than nothing) and call
> that one instead. With the use case used as example in this issue, that would
> mean ending up doing the equivalent of:
> {{noformat}}
> java.util.TimeZone.class.getMethod("getOffset",
> long.class).invoke(TimeZone.getDefault(), 0);
> {{noformat}}
> which, from JVM point of view, is covered by the {{--add-opens
> java.base/java.util=ALL-UNNAMED}}.
> It would be a big change, but at least can't think of any retro-compatibility
> problem it might cause.
> One might be tempted to answer "just add {{--add-opens
> java.base/sun.util.calendar=ALL-UNNAMED}}" but it does not seem fair as this
> is not what the API that the script uses was exposing at all, you might need
> to document a different one for each JVM implementation (even if it's
> probably unlikely for this specific example) but more importantly you will
> potentially need quite a lot of those and will only discover it at runtime
> since it's not so easy to guess from an API in which you only know the public
> JVM classes since that's what you manipulate.
> I would be happy to work on this, but I wanted first ask what others think
> about this problem in general and the possible solutions I may have missed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Closed] (VELOCITY-895) Implement implicit integer conversion for integer range iteration
[
https://issues.apache.org/jira/browse/VELOCITY-895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed VELOCITY-895.
---
> Implement implicit integer conversion for integer range iteration
> -
>
> Key: VELOCITY-895
> URL: https://issues.apache.org/jira/browse/VELOCITY-895
> Project: Velocity
> Issue Type: Improvement
> Components: Engine
>Affects Versions: 2.0
>Reporter: Claude Brisson
>Assignee: Claude Brisson
>Priority: Minor
> Fix For: 2.1.x
>
>
> In expression:
> {{#foreach($i in [$min .. $max])}}
> {{$min}} and {{$max}} should be implicitely converted to integers.
>
--
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-950) Skipping empty lines
[ https://issues.apache.org/jira/browse/VELOCITY-950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17464030#comment-17464030 ] Michael Osipov commented on VELOCITY-950: - Also read and try: https://velocity.apache.org/engine/2.3/developer-guide.html#space-gobbling > Skipping empty lines > > > Key: VELOCITY-950 > URL: https://issues.apache.org/jira/browse/VELOCITY-950 > Project: Velocity > Issue Type: Wish > Components: Engine >Reporter: Ivan Galkin >Priority: Major > > I need to convert text from Word to PDF using "if" (or others) construction > of Velocity. I need to get rid of empty lines. > Example: > In Word it looks like: > «#if(xxx == "true)»1«#end» > «#if(yyy == "true)»1«#end» > «#if(zzz == "true)»1«#end» > If yyy == false, xxx and zzz are true in PDF we will get: > 1 > > 1 > But I need get it without an empty line somehow: > 1 > 1 > Is it possible to do it with such functionality? -- 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-950) Skipping empty lines
[ https://issues.apache.org/jira/browse/VELOCITY-950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17464029#comment-17464029 ] Michael Osipov commented on VELOCITY-950: - This is syntactially not valid. No quotes aren't balanced. > Skipping empty lines > > > Key: VELOCITY-950 > URL: https://issues.apache.org/jira/browse/VELOCITY-950 > Project: Velocity > Issue Type: Wish > Components: Engine >Reporter: Ivan Galkin >Priority: Major > > I need to convert text from Word to PDF using "if" (or others) construction > of Velocity. I need to get rid of empty lines. > Example: > In Word it looks like: > «#if(xxx == "true)»1«#end» > «#if(yyy == "true)»1«#end» > «#if(zzz == "true)»1«#end» > If yyy == false, xxx and zzz are true in PDF we will get: > 1 > > 1 > But I need get it without an empty line somehow: > 1 > 1 > Is it possible to do it with such functionality? -- 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-950) Skipping empty lines
[ https://issues.apache.org/jira/browse/VELOCITY-950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17464022#comment-17464022 ] Michael Osipov commented on VELOCITY-950: - Please provide an executable Velocity template snippet. Your one isn't even syntactically valid. > Skipping empty lines > > > Key: VELOCITY-950 > URL: https://issues.apache.org/jira/browse/VELOCITY-950 > Project: Velocity > Issue Type: Wish > Components: Engine >Reporter: Ivan Galkin >Priority: Major > > I need to convert text from Word to PDF using "if" (or others) construction > of Velocity. I need to get rid of empty lines. > Example: > In Word it looks like: > «#if(xxx == "true)»1«#end» > «#if(yyy == "true)»1«#end» > «#if(zzz == "true)»1«#end» > If yyy == false, xxx and zzz are true in PDF we will get: > 1 > > 1 > But I need get it without an empty line somehow: > 1 > 1 > Is it possible to do it with such functionality? -- 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-950) Skipping empty lines
[ https://issues.apache.org/jira/browse/VELOCITY-950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463845#comment-17463845 ] Michael Osipov commented on VELOCITY-950: - Execute in Word? Are you certain that this is the correct project? > Skipping empty lines > > > Key: VELOCITY-950 > URL: https://issues.apache.org/jira/browse/VELOCITY-950 > Project: Velocity > Issue Type: Wish > Components: Engine >Reporter: Ivan Galkin >Priority: Major > > I need to convert text from Word to PDF using "if" (or others) construction > of Velocity. I need to get rid of empty lines. > Example: > In Word it looks like: > «#if(xxx == "true)»1«#end» > «#if(yyy == "true)»1«#end» > «#if(zzz == "true)»1«#end» > If yyy == false, xxx and zzz are true in PDF we will get: > 1 > > 1 > But I need get it without an empty line somehow: > 1 > 1 > Is it possible to do it with such functionality? -- 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] (VELOCITY-945) Error Configuring Velocity
[ https://issues.apache.org/jira/browse/VELOCITY-945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed VELOCITY-945. --- Resolution: Invalid > Error Configuring Velocity > --- > > Key: VELOCITY-945 > URL: https://issues.apache.org/jira/browse/VELOCITY-945 > Project: Velocity > Issue Type: Task > Components: Engine >Affects Versions: 2.3 > Environment: Software platform >Reporter: Pooja >Priority: Major > > When upgrading Wildfly Server to 20, we get a error configuring velocity > error every second build. The error does not occur on the first build or if > the subsequent builds have code changes. But if deploying multiple times, the > error occurs intermittently. > > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Closed] (VELOCITY-920) ParseErrorException with square brackets without leading space in velocity 2.1 from 1.4
[ https://issues.apache.org/jira/browse/VELOCITY-920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed VELOCITY-920. --- > ParseErrorException with square brackets without leading space in velocity > 2.1 from 1.4 > --- > > Key: VELOCITY-920 > URL: https://issues.apache.org/jira/browse/VELOCITY-920 > Project: Velocity > Issue Type: Bug >Affects Versions: 2.1 >Reporter: swati agarwal >Assignee: Claude Brisson >Priority: Major > Attachments: HelloWorld.java, helloworld.vm > > > I have upgraded from velocity 1.4 to velocity-engine-core 2.1. > I have also added the properties for backward compatibilty as mentioned in > the page https://velocity.apache.org/engine/2.1/upgrading.html. > However, with the new jar I am getting parse exception with the getTemplate > method for vm file having content '$methodName[]'. This was working with > velocity 1.4 -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-920) ParseErrorException with square brackets without leading space in velocity 2.1 from 1.4
[ https://issues.apache.org/jira/browse/VELOCITY-920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated VELOCITY-920: Fix Version/s: (was: 1.7.x) > ParseErrorException with square brackets without leading space in velocity > 2.1 from 1.4 > --- > > Key: VELOCITY-920 > URL: https://issues.apache.org/jira/browse/VELOCITY-920 > Project: Velocity > Issue Type: Bug >Affects Versions: 2.1 >Reporter: swati agarwal >Assignee: Claude Brisson >Priority: Major > Attachments: HelloWorld.java, helloworld.vm > > > I have upgraded from velocity 1.4 to velocity-engine-core 2.1. > I have also added the properties for backward compatibilty as mentioned in > the page https://velocity.apache.org/engine/2.1/upgrading.html. > However, with the new jar I am getting parse exception with the getTemplate > method for vm file having content '$methodName[]'. This was working with > velocity 1.4 -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-949) Extra whitespaces in converting from Word to PDF
[ https://issues.apache.org/jira/browse/VELOCITY-949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated VELOCITY-949: Fix Version/s: (was: 1.7.x) > Extra whitespaces in converting from Word to PDF > > > Key: VELOCITY-949 > URL: https://issues.apache.org/jira/browse/VELOCITY-949 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 1.7.x >Reporter: Ivan Galkin >Priority: Major > > I need to convert text from Word to PDF using "if" construction of Velocity. > When I use it, i have an extra space before the value of if construction. How > can I get rid of it? > Example: > In Word it looks like: «#if(xxx == "true)»1«#else»0«#end» > But in PDF we will get: > 1 > Instead of: > 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] [Updated] (VELOCITY-949) Extra whitespaces in converting from Word to PDF
[ https://issues.apache.org/jira/browse/VELOCITY-949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated VELOCITY-949: Affects Version/s: (was: 1.7.x) > Extra whitespaces in converting from Word to PDF > > > Key: VELOCITY-949 > URL: https://issues.apache.org/jira/browse/VELOCITY-949 > Project: Velocity > Issue Type: Bug > Components: Engine >Reporter: Ivan Galkin >Priority: Major > > I need to convert text from Word to PDF using "if" construction of Velocity. > When I use it, i have an extra space before the value of if construction. How > can I get rid of it? > Example: > In Word it looks like: «#if(xxx == "true)»1«#else»0«#end» > But in PDF we will get: > 1 > Instead of: > 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] [Commented] (VELOCITY-949) Extra whitespaces in converting from Word to PDF
[ https://issues.apache.org/jira/browse/VELOCITY-949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463780#comment-17463780 ] Michael Osipov commented on VELOCITY-949: - Your request is confusing me?! PDF is a binary format. Velocity produces text formats. Please explain. > Extra whitespaces in converting from Word to PDF > > > Key: VELOCITY-949 > URL: https://issues.apache.org/jira/browse/VELOCITY-949 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 1.7.x >Reporter: Ivan Galkin >Priority: Major > Fix For: 1.7.x > > > I need to convert text from Word to PDF using "if" construction of Velocity. > When I use it, i have an extra space before the value of if construction. How > can I get rid of it? > Example: > In Word it looks like: «#if(xxx == "true)»1«#else»0«#end» > But in PDF we will get: > 1 > Instead of: > 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] [Updated] (VELOCITY-950) Skipping empty lines
[ https://issues.apache.org/jira/browse/VELOCITY-950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated VELOCITY-950: Affects Version/s: (was: 1.7.x) > Skipping empty lines > > > Key: VELOCITY-950 > URL: https://issues.apache.org/jira/browse/VELOCITY-950 > Project: Velocity > Issue Type: Wish > Components: Engine >Reporter: Ivan Galkin >Priority: Major > > I need to convert text from Word to PDF using "if" (or others) construction > of Velocity. I need to get rid of empty lines. > Example: > In Word it looks like: > «#if(xxx == "true)»1«#end» > «#if(yyy == "true)»1«#end» > «#if(zzz == "true)»1«#end» > If yyy == false, xxx and zzz are true in PDF we will get: > 1 > 1 > But I need get it without an empty line somehow: > 1 > 1 > Is it possible to do it with such functionality? -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-950) Skipping empty lines
[ https://issues.apache.org/jira/browse/VELOCITY-950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated VELOCITY-950: Fix Version/s: (was: 1.7.x) > Skipping empty lines > > > Key: VELOCITY-950 > URL: https://issues.apache.org/jira/browse/VELOCITY-950 > Project: Velocity > Issue Type: Wish > Components: Engine >Affects Versions: 1.7.x >Reporter: Ivan Galkin >Priority: Major > > I need to convert text from Word to PDF using "if" (or others) construction > of Velocity. I need to get rid of empty lines. > Example: > In Word it looks like: > «#if(xxx == "true)»1«#end» > «#if(yyy == "true)»1«#end» > «#if(zzz == "true)»1«#end» > If yyy == false, xxx and zzz are true in PDF we will get: > 1 > 1 > But I need get it without an empty line somehow: > 1 > 1 > Is it possible to do it with such functionality? -- 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-950) Skipping empty lines
[ https://issues.apache.org/jira/browse/VELOCITY-950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463779#comment-17463779 ] Michael Osipov commented on VELOCITY-950: - Your request is confusing me?! PDF is a binary format. Velocity produces text formats. Please explain. > Skipping empty lines > > > Key: VELOCITY-950 > URL: https://issues.apache.org/jira/browse/VELOCITY-950 > Project: Velocity > Issue Type: Wish > Components: Engine >Affects Versions: 1.7.x >Reporter: Ivan Galkin >Priority: Major > Fix For: 1.7.x > > > I need to convert text from Word to PDF using "if" (or others) construction > of Velocity. I need to get rid of empty lines. > Example: > In Word it looks like: > «#if(xxx == "true)»1«#end» > «#if(yyy == "true)»1«#end» > «#if(zzz == "true)»1«#end» > If yyy == false, xxx and zzz are true in PDF we will get: > 1 > 1 > But I need get it without an empty line somehow: > 1 > 1 > Is it possible to do it with such functionality? -- 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=17413491#comment-17413491
]
Michael Osipov commented on VELOCITY-948:
-
I agree with [~cbrisson] that updating ranges makes no sense.
> 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] [Closed] (VELOCITY-947) Input macro variable not changed outside scope
[
https://issues.apache.org/jira/browse/VELOCITY-947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed VELOCITY-947.
---
Resolution: Not A Problem
Closing by request of [~fabio.nb].
> Input macro variable not changed outside scope
> --
>
> Key: VELOCITY-947
> URL: https://issues.apache.org/jira/browse/VELOCITY-947
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 1.7.x
>Reporter: Fabio Nascimento Brandão
>Priority: Major
> Attachments: variable_velocity.tar.gz
>
>
> I am migrating an application from Velocity Engine 1.5 to 1.7 (I am planning
> to migrate to 2.x later) and I found a different behavior between 1.5, 1.6.x
> and 1.7 versions.
> If you have this template:
> {code:java}
> #macro(testMacro $variable $newValue)
> #set($variable = $newValue)
> #end
> #set($testevar = 'INCORRECT')
> Var before: $testevar
> #testMacro($testevar 'TEST OK')
> Var after: $testevar
> {code}
> The output for the versions 1.5, 1.6, 1.6.2, 1.6.3 and 1.6.4 are:
> {code:java}
> Var before: INCORRECT
> Var after: TEST OK
> {code}
> And for versions 1.6.1 and 1.7 are:
> {code:java}
> Var before: INCORRECT
> Var after: INCORRECT
> {code}
> In 1.5, the set inside macro was changing the referenced variable outside
> macro's scope. In 1.6.1 and 1.7 the variable is not changed.
> I think this change was introduced by this issue:
> https://issues.apache.org/jira/browse/VELOCITY-615
> In this method:
>
> [https://github.com/apache/velocity-engine/commit/e0dec30ef0107ba0066fa18facdc1f7f2677087c#diff-79959d90eea878dd1d2550fa30aff8653a583339fe8125133b6a23573f2a0848L169-R173]
> Before the change, the context was updated with the key from getRootString()
> method.
> I am attaching a project with the tests. You can change the velocity version
> in _build.gradle_ and run with _./gradlew run_
--
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-947) Input macro variable not changed outside scope
[
https://issues.apache.org/jira/browse/VELOCITY-947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17394962#comment-17394962
]
Michael Osipov commented on VELOCITY-947:
-
Please test 2.x only, we won't do any fixes on 1.x anymore.
> Input macro variable not changed outside scope
> --
>
> Key: VELOCITY-947
> URL: https://issues.apache.org/jira/browse/VELOCITY-947
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 1.7.x
>Reporter: Fabio Nascimento Brandão
>Priority: Major
> Attachments: variable_velocity.tar.gz
>
>
> I am migrating an application from Velocity Engine 1.5 to 1.7 (I am planning
> to migrate to 2.x later) and I found a different behavior between 1.5, 1.6.x
> and 1.7 versions.
> If you have this template:
> {code:java}
> #macro(testMacro $variable $newValue)
> #set($variable = $newValue)
> #end
> #set($testevar = 'INCORRECT')
> Var before: $testevar
> #testMacro($testevar 'TEST OK')
> Var after: $testevar
> {code}
> The output for the versions 1.5, 1.6, 1.6.2, 1.6.3 and 1.6.4 are:
> {code:java}
> Var before: INCORRECT
> Var after: TEST OK
> {code}
> And for versions 1.6.1 and 1.7 are:
> {code:java}
> Var before: INCORRECT
> Var after: INCORRECT
> {code}
> In 1.5, the set inside macro was changing the referenced variable outside
> macro's scope. In 1.6.1 and 1.7 the variable is not changed.
> I think this change was introduced by this issue:
> https://issues.apache.org/jira/browse/VELOCITY-615
> In this method:
>
> [https://github.com/apache/velocity-engine/commit/e0dec30ef0107ba0066fa18facdc1f7f2677087c#diff-79959d90eea878dd1d2550fa30aff8653a583339fe8125133b6a23573f2a0848L169-R173]
> Before the change, the context was updated with the key from getRootString()
> method.
> I am attaching a project with the tests. You can change the velocity version
> in _build.gradle_ and run with _./gradlew run_
--
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-946) Questions about the existing velocity safety mechanism
[
https://issues.apache.org/jira/browse/VELOCITY-946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed VELOCITY-946.
---
Resolution: Invalid
Questions aren't bugs. We have a mailing list for that.
> Questions about the existing velocity safety mechanism
> --
>
> Key: VELOCITY-946
> URL: https://issues.apache.org/jira/browse/VELOCITY-946
> Project: Velocity
> Issue Type: Bug
>Reporter: n4nch341
>Priority: Major
>
> hello sir:
> I noticed that velocity-core fixes CVE-2020-13936
> https://github.com/apache/velocity-engine/pull/16/files, but follow content
>
> "introspector.restrict.classes =
> org.apache.catalina.core.DefaultInstanceManager
> introspector.restrict.classes = org.apache.tomcat.SimpleInstanceManager
> introspector.restrict.classes =
> org.wildfly.extension.undertow.deployment.UndertowJSPInstanceManager
> introspector.restrict.classes = org.eclipse.jetty.util.DecoratedObjectFactory"
>
> be added in the
> velocity-engine-core/src/test/resources/oldproperties/velocity.properties
> file. I think this is a test file and wouldn't take effect at runtime.
>
> As for the valid org\apache\velocity\runtime\defaults\velocity.properties
> file Has not been added to these blacklists, so in the velocity-tools-view
> framework
> $\{req.getServletContext().getAttribute('org.apache.tomcat.InstanceManager').newInstance('javax.script.ScriptEngineManager').getEngineByName
> ('js').eval(xx) This payload is still valid, and the Velocity-tools-view
> does not enable SecureUberspector by default.
> so I don’t know that writing this blacklist under the test file means that
> the application that calls velocity-core needs its own to add blacklists or
> is it because velocity-core forgot to add these blacklists to
> org\apache\velocity\runtime\defaults\velocity.properties, can this be
> considered a vulnerability?
--
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-945) Error Configuring Velocity
[ https://issues.apache.org/jira/browse/VELOCITY-945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17352078#comment-17352078 ] Michael Osipov commented on VELOCITY-945: - So what? > Error Configuring Velocity > --- > > Key: VELOCITY-945 > URL: https://issues.apache.org/jira/browse/VELOCITY-945 > Project: Velocity > Issue Type: Task > Components: Engine >Affects Versions: 2.3 > Environment: Software platform >Reporter: Pooja >Priority: Major > > When upgrading Wildfly Server to 20, we get a error configuring velocity > error every second build. The error does not occur on the first build or if > the subsequent builds have code changes. But if deploying multiple times, the > error occurs intermittently. > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-942) VelocityViewServlet extending from jakarta.servlet instead of javax.servlet
[ https://issues.apache.org/jira/browse/VELOCITY-942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17307731#comment-17307731 ] Michael Osipov commented on VELOCITY-942: - Do you require that for your projects? javax namespace will continue to live to at least 5 more years if not 10 in enterprise... > VelocityViewServlet extending from jakarta.servlet instead of javax.servlet > --- > > Key: VELOCITY-942 > URL: https://issues.apache.org/jira/browse/VELOCITY-942 > Project: Velocity > Issue Type: New Feature > Components: Engine >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.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-937) Please delete old releases from mirroring system
[ https://issues.apache.org/jira/browse/VELOCITY-937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed VELOCITY-937. --- Resolution: Done Stuff deleted. > Please delete old releases from mirroring system > > > Key: VELOCITY-937 > URL: https://issues.apache.org/jira/browse/VELOCITY-937 > Project: Velocity > Issue Type: Task > Environment: https://dist.apache.org/repos/dist/release/velocity >Reporter: Sebb >Assignee: Michael Osipov >Priority: Major > > To reduce the load on the ASF mirrors, projects are required to archive old > releases [1] > It's unfair to expect the 3rd party mirrors to carry old releases. > Please can you archive all non-current releases? > [Remember to update the download page before dropping the files from > dist.apache.org!] > The following releases appear to be non-current: > https://dist.apache.org/repos/dist/release/velocity/engine/1.7 > https://dist.apache.org/repos/dist/release/velocity/engine/2.0 > https://dist.apache.org/repos/dist/release/velocity/engine/2.1 > https://dist.apache.org/repos/dist/release/velocity/tools/1.4/ > https://dist.apache.org/repos/dist/release/velocity/tools/2.0/ > If necessary, please also update your release procedures to ensure old > releases are archived > once a new release has been published. > Thanks! > [1] http://www.apache.org/dev/release.html#when-to-archive -- 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-937) Please delete old releases from mirroring system
[ https://issues.apache.org/jira/browse/VELOCITY-937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reassigned VELOCITY-937: --- Assignee: Michael Osipov > Please delete old releases from mirroring system > > > Key: VELOCITY-937 > URL: https://issues.apache.org/jira/browse/VELOCITY-937 > Project: Velocity > Issue Type: Task > Environment: https://dist.apache.org/repos/dist/release/velocity >Reporter: Sebb >Assignee: Michael Osipov >Priority: Major > > To reduce the load on the ASF mirrors, projects are required to archive old > releases [1] > It's unfair to expect the 3rd party mirrors to carry old releases. > Please can you archive all non-current releases? > [Remember to update the download page before dropping the files from > dist.apache.org!] > The following releases appear to be non-current: > https://dist.apache.org/repos/dist/release/velocity/engine/1.7 > https://dist.apache.org/repos/dist/release/velocity/engine/2.0 > https://dist.apache.org/repos/dist/release/velocity/engine/2.1 > https://dist.apache.org/repos/dist/release/velocity/tools/1.4/ > https://dist.apache.org/repos/dist/release/velocity/tools/2.0/ > If necessary, please also update your release procedures to ensure old > releases are archived > once a new release has been published. > Thanks! > [1] http://www.apache.org/dev/release.html#when-to-archive -- 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-934) NullPointerException under high concurrency
[
https://issues.apache.org/jira/browse/VELOCITY-934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed VELOCITY-934.
---
Resolution: Information Provided
> 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-934) NullPointerException under high concurrency
[
https://issues.apache.org/jira/browse/VELOCITY-934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17246080#comment-17246080
]
Michael Osipov commented on VELOCITY-934:
-
Can we close this one?
> 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
