[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] [Commented] (VELTOOLS-206) Upgrade to Velocity Engine 2.4.2
[ https://issues.apache.org/jira/browse/VELTOOLS-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823138#comment-17823138 ] Claude Brisson commented on VELTOOLS-206: - 2.4.2 ?! So you're not comming back to 2.4? I don't understand why. Even if a tag is public, you can delete it. > Upgrade to Velocity Engine 2.4.2 > > > Key: VELTOOLS-206 > URL: https://issues.apache.org/jira/browse/VELTOOLS-206 > Project: Velocity Tools > Issue Type: Task >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 3.2.1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [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] (VELOCITY-978) Project Loom/Jdk21 Support?
Patrick Barry created VELOCITY-978: -- Summary: 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 |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] (VELOCITY-977) Upgrade Java Compiler Compiler to Version 7.0.13
Sylwester Lachiewicz created VELOCITY-977: - Summary: 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 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-975) Unicode characters cause issues
[
https://issues.apache.org/jira/browse/VELOCITY-975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817935#comment-17817935
]
Alex O'Ree commented on VELOCITY-975:
-
striping it out before sending to velocity is a work around, but it's far from
ideal. It's hard to know what characters it will joke on. hmm, maybe i can rig
up a test to simple test all of the characters until a pattern emerges. I'm
working with content extract from an office document so there's absolutely no
guarantee that the character set can be entirely cleaned up.
Do you know what character set velocity is restricted to?
> 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] [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] [Created] (VELOCITY-975) Unicode characters cause issues
Alex O'Ree created VELOCITY-975: --- Summary: 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 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) -- This message was sent by Atlassian Jira (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] [Commented] (VELOCITY-970) velocity-engine-core contains commons-io Maven descriptor
[ https://issues.apache.org/jira/browse/VELOCITY-970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17805711#comment-17805711 ] Thomas Mortagne commented on VELOCITY-970: -- OK, I actually did not know the shade plugin was also modifying the pom. > velocity-engine-core contains commons-io Maven descriptor > - > > Key: VELOCITY-970 > URL: https://issues.apache.org/jira/browse/VELOCITY-970 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.3 >Reporter: Thomas Mortagne >Priority: Major > > commons-io is embedded in velocity-engine-core, which is OK from Java point > of view since its package is renamed (not causing any dependency problems). > The problem is that it contains the commons-io Maven descriptors at the > standard location (/META-INF/maven/commons-io/commons-io/), which is a > problem when you analyze JAR files to find what's in it because it ends up > being identified as a JAR exposing commons-io (which is not the case since > it's weaved). > Honestly, it feels very strange to embed commons-io in the first place given > that commons-lang for example is a transitive dependency, so I feel like the > simplest would just be to remove all the plumbing to embed and weave > commons-io and simply keep it as a regular transitive dependency. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-970) velocity-engine-core contains commons-io Maven descriptor
[ https://issues.apache.org/jira/browse/VELOCITY-970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17805706#comment-17805706 ] Claude Brisson commented on VELOCITY-970: - That's not strange, that's an effect of the shading: one pom is to compile it, one to use it at runtime. > velocity-engine-core contains commons-io Maven descriptor > - > > Key: VELOCITY-970 > URL: https://issues.apache.org/jira/browse/VELOCITY-970 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.3 >Reporter: Thomas Mortagne >Priority: Major > > commons-io is embedded in velocity-engine-core, which is OK from Java point > of view since its package is renamed (not causing any dependency problems). > The problem is that it contains the commons-io Maven descriptors at the > standard location (/META-INF/maven/commons-io/commons-io/), which is a > problem when you analyze JAR files to find what's in it because it ends up > being identified as a JAR exposing commons-io (which is not the case since > it's weaved). > Honestly, it feels very strange to embed commons-io in the first place given > that commons-lang for example is a transitive dependency, so I feel like the > simplest would just be to remove all the plumbing to embed and weave > commons-io and simply keep it as a regular transitive dependency. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-970) velocity-engine-core contains commons-io Maven descriptor
[ https://issues.apache.org/jira/browse/VELOCITY-970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17805700#comment-17805700 ] Thomas Mortagne commented on VELOCITY-970: -- bq. we should include it as a direct dependency Strangely it seems to be the case on github (https://github.com/apache/velocity-engine/blob/master/velocity-engine-core/pom.xml#L322) but it's not in the 2.3 pom deployed on Maven Central. > velocity-engine-core contains commons-io Maven descriptor > - > > Key: VELOCITY-970 > URL: https://issues.apache.org/jira/browse/VELOCITY-970 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.3 >Reporter: Thomas Mortagne >Priority: Major > > commons-io is embedded in velocity-engine-core, which is OK from Java point > of view since its package is renamed (not causing any dependency problems). > The problem is that it contains the commons-io Maven descriptors at the > standard location (/META-INF/maven/commons-io/commons-io/), which is a > problem when you analyze JAR files to find what's in it because it ends up > being identified as a JAR exposing commons-io (which is not the case since > it's weaved). > Honestly, it feels very strange to embed commons-io in the first place given > that commons-lang for example is a transitive dependency, so I feel like the > simplest would just be to remove all the plumbing to embed and weave > commons-io and simply keep it as a regular transitive dependency. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-970) velocity-engine-core contains commons-io Maven descriptor
[ https://issues.apache.org/jira/browse/VELOCITY-970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17805605#comment-17805605 ] Thomas Mortagne commented on VELOCITY-970: -- Proposal pull request on https://github.com/apache/velocity-engine/pull/37. > velocity-engine-core contains commons-io Maven descriptor > - > > Key: VELOCITY-970 > URL: https://issues.apache.org/jira/browse/VELOCITY-970 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.3 >Reporter: Thomas Mortagne >Priority: Major > > commons-io is embedded in velocity-engine-core, which is OK from Java point > of view since its package is renamed (not causing any dependency problems). > The problem is that it contains the commons-io Maven descriptors at the > standard location (/META-INF/maven/commons-io/commons-io/), which is a > problem when you analyze JAR files to find what's in it because it ends up > being identified as a JAR exposing commons-io (which is not the case since > it's weaved). > Honestly, it feels very strange to embed commons-io in the first place given > that commons-lang for example is a transitive dependency, so I feel like the > simplest would just be to remove all the plumbing to embed and weave > commons-io and simply keep it as a regular transitive dependency. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-970) velocity-engine-core contains commons-io Maven descriptor
[ https://issues.apache.org/jira/browse/VELOCITY-970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17805605#comment-17805605 ] Thomas Mortagne edited comment on VELOCITY-970 at 1/11/24 2:04 PM: --- Proposal pull request available on https://github.com/apache/velocity-engine/pull/37. was (Author: tmortagne): Proposal pull request on https://github.com/apache/velocity-engine/pull/37. > velocity-engine-core contains commons-io Maven descriptor > - > > Key: VELOCITY-970 > URL: https://issues.apache.org/jira/browse/VELOCITY-970 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.3 >Reporter: Thomas Mortagne >Priority: Major > > commons-io is embedded in velocity-engine-core, which is OK from Java point > of view since its package is renamed (not causing any dependency problems). > The problem is that it contains the commons-io Maven descriptors at the > standard location (/META-INF/maven/commons-io/commons-io/), which is a > problem when you analyze JAR files to find what's in it because it ends up > being identified as a JAR exposing commons-io (which is not the case since > it's weaved). > Honestly, it feels very strange to embed commons-io in the first place given > that commons-lang for example is a transitive dependency, so I feel like the > simplest would just be to remove all the plumbing to embed and weave > commons-io and simply keep it as a regular transitive dependency. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-970) velocity-engine-core contains commons-io Maven descriptor
[ https://issues.apache.org/jira/browse/VELOCITY-970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mortagne updated VELOCITY-970: - Description: commons-io is embedded in velocity-engine-core, which is OK from Java point of view since its package is renamed (not causing any dependency problems). The problem is that it contains the commons-io Maven descriptors at the standard location (/META-INF/maven/commons-io/commons-io/), which is a problem when you analyze JAR files to find what's in it because it ends up being identified as a JAR exposing commons-io (which is not the case since it's weaved). Honestly, it feels very strange to embed commons-io in the first place given that commons-lang for example is a transitive dependency, so I feel like the simplest would just be to remove all the plumbing to embed and weave commons-io and simply keep it as a regular transitive dependency. was: commons-io is embedded in velocity-engine-core, which is OK from Java point of view since its package is renamed (not causing any dependency problems). The problem is that it contains the commons-io Maven descriptors at the standard location (/META-INF/maven/commons-io/commons-io/), which is a problem when you analyze JAR files to find what's in it because it ends up being identified as a JAR exposing commons-io (which is not the case since it's weaved). Honestly, it feels very strange to embed commons-io in the first place given that commons-lang for example is a transitive dependency, so I feel like the simplest would just be to remove all the plumbing to embed and weave commons-io and simply keep it as transitive dependency. > velocity-engine-core contains commons-io Maven descriptor > - > > Key: VELOCITY-970 > URL: https://issues.apache.org/jira/browse/VELOCITY-970 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.3 >Reporter: Thomas Mortagne >Priority: Major > > commons-io is embedded in velocity-engine-core, which is OK from Java point > of view since its package is renamed (not causing any dependency problems). > The problem is that it contains the commons-io Maven descriptors at the > standard location (/META-INF/maven/commons-io/commons-io/), which is a > problem when you analyze JAR files to find what's in it because it ends up > being identified as a JAR exposing commons-io (which is not the case since > it's weaved). > Honestly, it feels very strange to embed commons-io in the first place given > that commons-lang for example is a transitive dependency, so I feel like the > simplest would just be to remove all the plumbing to embed and weave > commons-io and simply keep it as a regular transitive dependency. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-970) velocity-engine-core contains commons-io Maven descriptor
[ https://issues.apache.org/jira/browse/VELOCITY-970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mortagne updated VELOCITY-970: - Description: commons-io is embedded in velocity-engine-core, which is OK from Java point of view since its package is renamed (not causing any dependency problems). The problem is that it contains the commons-io Maven descriptors at the standard location (/META-INF/maven/commons-io/commons-io/), which is a problem when you analyze JAR files to find what's in it because it ends up being identified as a JAR exposing commons-io (which is not the case since it's weaved). Honestly, it feels very strange to embed commons-io in the first place given that commons-lang for example is a transitive dependency, so I feel like the simplest would just be to remove all the plumbing to embed and weave commons-io and simply keep it as transitive dependency. was: commons-io is embedded in velocity-engine-core, which is OK from Java point of view since it's weaved (not causing any dependency problems). The problem is that it contains the commons-io Maven descriptors at the standard location (/META-INF/maven/commons-io/commons-io/), which is a problem when you analyze JAR files to find what's in it because it ends up being identified as a JAR exposing commons-io (which is not the case since it's weaved). Honestly, it feels very strange to embed commons-io in the first place given that commons-lang for example is a transitive dependency, so I feel like the simplest would just be to remove all the plumbing to embed and weave commons-io and simply keep it as transitive dependency. > velocity-engine-core contains commons-io Maven descriptor > - > > Key: VELOCITY-970 > URL: https://issues.apache.org/jira/browse/VELOCITY-970 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.3 >Reporter: Thomas Mortagne >Priority: Major > > commons-io is embedded in velocity-engine-core, which is OK from Java point > of view since its package is renamed (not causing any dependency problems). > The problem is that it contains the commons-io Maven descriptors at the > standard location (/META-INF/maven/commons-io/commons-io/), which is a > problem when you analyze JAR files to find what's in it because it ends up > being identified as a JAR exposing commons-io (which is not the case since > it's weaved). > Honestly, it feels very strange to embed commons-io in the first place given > that commons-lang for example is a transitive dependency, so I feel like the > simplest would just be to remove all the plumbing to embed and weave > commons-io and simply keep it as transitive dependency. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Created] (VELOCITY-970) velocity-engine-core contains commons-io Maven descriptor
Thomas Mortagne created VELOCITY-970: Summary: velocity-engine-core contains commons-io Maven descriptor Key: VELOCITY-970 URL: https://issues.apache.org/jira/browse/VELOCITY-970 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 2.3 Reporter: Thomas Mortagne commons-io is embedded in velocity-engine-core, which is OK from Java point of view since it's weaved (not causing any dependency problems). The problem is that it contains the commons-io Maven descriptors at the standard location (/META-INF/maven/commons-io/commons-io/), which is a problem when you analyze JAR files to find what's in it because it ends up being identified as a JAR exposing commons-io (which is not the case since it's weaved). Honestly, it feels very strange to embed commons-io in the first place given that commons-lang for example is a transitive dependency, so I feel like the simplest would just be to remove all the plumbing to embed and weave commons-io and simply keep it as transitive dependency. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [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=17805082#comment-17805082 ] Martin Tzvetanov Grigorov edited comment on VELTOOLS-202 at 1/10/24 11:33 AM: -- OK, we have a progress on the technical part! Let's continue! Which module has been renamed ? In https://github.com/apache/velocity-tools/pull/15/files I don't see renamed (Maven?!) module. I see updated Maven dependencies and updated Java imports. This matches with my idea of having two branches - one for javax and one for jakarta. The contributor offered a PR against `master` branch. Here any Velocity maintainer can create a branch for Javax from master before merging this PR and use this new branch for Javax releases and use master for Jakarta releases. The (Maven) version in the PR should be updated to 4.0-SNAPSHOT too. Later when there is a fix/improvement in either branches the maintainers could easily use `git cherry-pick -x someSHA` to port the commit to the other branch, if needed. If the cherry-pick fails then some manual work may be needed! It is a small effort! But the maintainer could always ask the contributor to open a second PR for the other branch if the effort is bigger! The release manager will have to make two releases until there are users for Javax but this is how it is. Again I think this is little extra work! You can also explain how you think it should be done and hopefully someone will do it one day! was (Author: mgrigorov): OK, we have a progress on the technical part! Let's continue! Which module has been renamed ? In https://github.com/apache/velocity-tools/pull/15/files I don't see renamed (Maven?!) module. I see updated Maven dependencies and updated Java imports. This matches with my idea of having two branches - one for javax and one for jakarta. The contributor offered a PR against `master` branch. Here any Velocity maintainer can create a branch for Javax from master before merging this PR and use this new branch for Javax releases and use master for Jakarta releases. The Maven version in the PR should be updated to 4.0-SNAPSHOT too. Later when there is a fix/improvement in either branches the maintainers could easily use `git cherry-pick -x someSHA` to port the commit to the other branch, if needed. If the cherry-pick fails then some manual work may be needed! It is a small effort! But the maintainer could always ask the contributor to open a second PR for the other branch if the effort is bigger! The release manager will have to make two releases until there are users for Javax but this is how it is. Again I think this is little extra work! You can also explain how you think it should be done and hopefully someone will do it one day! > 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=17805082#comment-17805082 ] Martin Tzvetanov Grigorov commented on VELTOOLS-202: OK, we have a progress on the technical part! Let's continue! Which module has been renamed ? In https://github.com/apache/velocity-tools/pull/15/files I don't see renamed (Maven?!) module. I see updated Maven dependencies and updated Java imports. This matches with my idea of having two branches - one for javax and one for jakarta. The contributor offered a PR against `master` branch. Here any Velocity maintainer can create a branch for Javax from master before merging this PR and use this new branch for Javax releases and use master for Jakarta releases. The Maven version in the PR should be updated to 4.0-SNAPSHOT too. Later when there is a fix/improvement in either branches the maintainers could easily use `git cherry-pick -x someSHA` to port the commit to the other branch, if needed. If the cherry-pick fails then some manual work may be needed! It is a small effort! But the maintainer could always ask the contributor to open a second PR for the other branch if the effort is bigger! The release manager will have to make two releases until there are users for Javax but this is how it is. Again I think this is little extra work! You can also explain how you think it should be done and hopefully someone will do it one day! > 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: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=17805044#comment-17805044 ] Martin Tzvetanov Grigorov commented on VELTOOLS-202: Define "reasonable"! Most people (me included) don't like being treated as in https://github.com/apache/velocity-tools/pull/15#issuecomment-1632855512 (closing the PR with a simple comment like "This can't be serious") The discussion in the mailing list could happen in parallel by asking the contributor more politely, or by starting it yourself, or by adding a comment how you think it should be done, or ... (many other options). Doing what you did there just gives bad impression to Velocity project and to Apache in general! IMO your behavior is not reasonable but this is getting personal, so let's stop! > 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=17804998#comment-17804998 ] Martin Tzvetanov Grigorov commented on VELTOOLS-202: I guess you want only the javax version of the code, otherwise this ticket won't be still opened after 3 years! ;-) Anyway, I am not a member of this project, so I have no voice here. > 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=17804979#comment-17804979 ] Martin Tzvetanov Grigorov commented on VELTOOLS-202: "single release management" is not something needed by the end users. The users need a release either for javax or for jakarta, not both in the same time. > 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=17804828#comment-17804828 ] Martin Tzvetanov Grigorov commented on VELTOOLS-202: I'd suggest to have two Git/SVN branches - one for javax and another for jakarta. Cherry-picking would be non-problematic most of the time. > 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=17804806#comment-17804806 ] Gernot Hueller commented on VELTOOLS-202: - [~michael-o] Yes that's what I also wrote in a mail to [dev@velocity.apache.org|mailto:dev@velocity.apache.org] to spawn a discussion - but the mail is in limbo for hours, not visible on lists.apache.org and also not rejected (I did not get an error mail) > 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] [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=17804718#comment-17804718 ] Gernot Hueller commented on VELTOOLS-202: - The velocity team treatment of the servlet API change is ridiculous. I see that the work HAS already been done but the pull request has been "closed". So it means that Velocity-tools wants to stay on an old API (was outdated october 2020) forever. So I will need to either clone the code and fix it myself. Or find a template engine that is not stuck in time. > 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] (VELOCITY-969) Lower scripts parser performance after update from 1.6 to 2.3 velocity version
[ https://issues.apache.org/jira/browse/VELOCITY-969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798141#comment-17798141 ] Magdalena Karpierz edited comment on VELOCITY-969 at 1/3/24 8:47 PM: - [~cbrisson] Below is an example that shows the difference in performance when parsing a script using velocity 1.6.3 and velocity 2.3. Parsed scripts are added as attachments: We have a main script (MainScript) that basically does nothing (and does not call any macro from the DependentScriptWithMacros file in this example) and a dependent large script with macros (DependentScriptWithMacros) that takes a long time to parse using Velocity 2.3. Macros in this example don't do anything useful, but I just want to show what type of structures we're dealing with. Is there anything that can be done to make velocity 2.3 parse this script at a similar speed to velocity 1.6.3 (maybe some properties configuration) ? ps. I know that this script with macros is not optimally written, but we cannot change it (due to too many such scripts and tests related to such changes). Below are logs from the execution of the same script (MainScript with a dependent script DependentScriptWithMacros) using velocity 1.6.3 and Velocity 2.3 logs from velocity 1.6.3 - 2023-12-13 13:05:44,481 CET DEBUG: Init message received. Will execute script [id = 2593271, outputRequired=true, userLanguage=en ] 2023-12-13 13:05:44,481 CET DEBUG: Main scriptId = 2593271 dependent scripts = 2593281, 2593271, 2023-12-13 13:05:44,488 CET INFO : using engine=Velocity 1.6.3, lang=Velocity Template Language 1.6.3 for script: DependentScriptWithMacros 2023-12-13 13:05:44,548 CET INFO : using engine=Velocity 1.6.3, lang=Velocity Template Language 1.6.3 for script: MainScript 2023-12-13 13:05:44,550 CET DEBUG: Script [id = 2593271] successfully executed. time of execution: 79 ms -- - logs from velocity 2.3 2023-12-13 13:14:12,170 CET DEBUG: Init message received. Will execute script [id = 2593271, outputRequired=true, userLanguage=en ] 2023-12-13 13:14:12,170 CET DEBUG: Main scriptId = 2593271 dependent scripts = 2593281, 2593271, 2023-12-13 13:14:12,195 CET WARN : configuration key 'resource.loader' has been deprecated in favor of 'resource.loaders' 2023-12-13 13:14:12,195 CET DEBUG: Initializing Velocity, Calling init()... 2023-12-13 13:14:12,196 CET DEBUG: Starting Apache Velocity v2.3 2023-12-13 13:14:12,197 CET DEBUG: Default Properties resource: org/apache/velocity20/runtime/defaults/velocity.properties 2023-12-13 13:14:12,213 CET DEBUG: ResourceLoader instantiated: org.apache.velocity20.runtime.resource.loader.FileResourceLoader 2023-12-13 13:14:12,213 CET DEBUG: FileResourceLoader: adding path '.' 2023-12-13 13:14:12,214 CET DEBUG: initialized (class org.apache.velocity20.runtime.resource.ResourceCacheImpl) with class java.util.Collections$SynchronizedMap cache map. 2023-12-13 13:14:12,216 CET DEBUG: Loaded System Directive: org.apache.velocity20.runtime.directive.Stop 2023-12-13 13:14:12,217 CET DEBUG: Loaded System Directive: org.apache.velocity20.runtime.directive.Define 2023-12-13 13:14:12,217 CET DEBUG: Loaded System Directive: org.apache.velocity20.runtime.directive.Break 2023-12-13 13:14:12,218 CET DEBUG: Loaded System Directive: org.apache.velocity20.runtime.directive.Evaluate 2023-12-13 13:14:12,218 CET DEBUG: Loaded System Directive: org.apache.velocity20.runtime.directive.Macro 2023-12-13 13:14:12,219 CET DEBUG: Loaded System Directive: org.apache.velocity20.runtime.directive.Parse 2023-12-13 13:14:12,220 CET DEBUG: Loaded System Directive: org.apache.velocity20.runtime.directive.Include 2023-12-13 13:14:12,221 CET DEBUG: Loaded System Directive: org.apache.velocity20.runtime.directive.Foreach 2023-12-13 13:14:12,243 CET DEBUG: Created '1' parsers. 2023-12-13 13:14:12,248 CET DEBUG: "velocimacro.library.path" is not set. Trying default library: velocimacros.vtl 2023-12-13 13:14:12,250 CET DEBUG: Default library velocimacros.vtl not found. Trying old default library: VM_global_library.vm 2023-12-13 13:14:12,250 CET DEBUG: Old default library VM_global_library.vm not found. 2023-12-13 13:14:12,250 CET DEBUG: allowInline = true: VMs can be defined inline in templates 2023-12-13 13:14:12,250 CET DEBUG: allowInlineToOverride = false: VMs defined inline may NOT replace previous VM definitions 2023-12-13 13:14:12,250 CET DEBUG: allowInlineLocal = false: VMs defined inline will be global in scope if allowed. 2023-12-13 13:14:12,250 CET DEBUG: autoload off: VM system will not automatically reload global library macros 2023-12-13 13:14:12,250 CET INFO : using engine=Velocity2 <>, lang=Velocity2 Template Language <> for script: DependentScriptWithMacros 2
[jira] [Commented] (VELOCITY-969) Lower scripts parser performance after update from 1.6 to 2.3 velocity version
[ https://issues.apache.org/jira/browse/VELOCITY-969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798141#comment-17798141 ] Magdalena Karpierz commented on VELOCITY-969: - Below is an example that shows the difference in performance when parsing a script using velocity 1.6.3 and velocity 2.3. Parsed scripts are added as attachments: We have a main script (MainScript) that basically does nothing (and does not call any macro from the DependentScriptWithMacros file in this example) and a dependent large script with macros (DependentScriptWithMacros) that takes a long time to parse using Velocity 2.3. Macros in this example don't do anything useful, but I just want to show what type of structures we're dealing with. Is there anything that can be done to make velocity 2.3 parse this script at a similar speed to velocity 1.6.3 (maybe some properties configuration) ? ps. I know that this script with macros is not optimally written, but we cannot change it (due to too many such scripts and tests related to such changes). Below are logs from the execution of the same script (MainScript with a dependent script DependentScriptWithMacros) using velocity 1.6.3 and Velocity 2.3 logs from velocity 1.6.3 - 2023-12-13 13:05:44,481 CET DEBUG: Init message received. Will execute script [id = 2593271, outputRequired=true, userLanguage=en ] 2023-12-13 13:05:44,481 CET DEBUG: Main scriptId = 2593271 dependent scripts = 2593281, 2593271, 2023-12-13 13:05:44,488 CET INFO : using engine=Velocity 1.6.3, lang=Velocity Template Language 1.6.3 for script: DependentScriptWithMacros 2023-12-13 13:05:44,548 CET INFO : using engine=Velocity 1.6.3, lang=Velocity Template Language 1.6.3 for script: MainScript 2023-12-13 13:05:44,550 CET DEBUG: Script [id = 2593271] successfully executed. time of execution: 79 ms -- - logs from velocity 2.3 2023-12-13 13:14:12,170 CET DEBUG: Init message received. Will execute script [id = 2593271, outputRequired=true, userLanguage=en ] 2023-12-13 13:14:12,170 CET DEBUG: Main scriptId = 2593271 dependent scripts = 2593281, 2593271, 2023-12-13 13:14:12,195 CET WARN : configuration key 'resource.loader' has been deprecated in favor of 'resource.loaders' 2023-12-13 13:14:12,195 CET DEBUG: Initializing Velocity, Calling init()... 2023-12-13 13:14:12,196 CET DEBUG: Starting Apache Velocity v2.3 2023-12-13 13:14:12,197 CET DEBUG: Default Properties resource: org/apache/velocity20/runtime/defaults/velocity.properties 2023-12-13 13:14:12,213 CET DEBUG: ResourceLoader instantiated: org.apache.velocity20.runtime.resource.loader.FileResourceLoader 2023-12-13 13:14:12,213 CET DEBUG: FileResourceLoader: adding path '.' 2023-12-13 13:14:12,214 CET DEBUG: initialized (class org.apache.velocity20.runtime.resource.ResourceCacheImpl) with class java.util.Collections$SynchronizedMap cache map. 2023-12-13 13:14:12,216 CET DEBUG: Loaded System Directive: org.apache.velocity20.runtime.directive.Stop 2023-12-13 13:14:12,217 CET DEBUG: Loaded System Directive: org.apache.velocity20.runtime.directive.Define 2023-12-13 13:14:12,217 CET DEBUG: Loaded System Directive: org.apache.velocity20.runtime.directive.Break 2023-12-13 13:14:12,218 CET DEBUG: Loaded System Directive: org.apache.velocity20.runtime.directive.Evaluate 2023-12-13 13:14:12,218 CET DEBUG: Loaded System Directive: org.apache.velocity20.runtime.directive.Macro 2023-12-13 13:14:12,219 CET DEBUG: Loaded System Directive: org.apache.velocity20.runtime.directive.Parse 2023-12-13 13:14:12,220 CET DEBUG: Loaded System Directive: org.apache.velocity20.runtime.directive.Include 2023-12-13 13:14:12,221 CET DEBUG: Loaded System Directive: org.apache.velocity20.runtime.directive.Foreach 2023-12-13 13:14:12,243 CET DEBUG: Created '1' parsers. 2023-12-13 13:14:12,248 CET DEBUG: "velocimacro.library.path" is not set. Trying default library: velocimacros.vtl 2023-12-13 13:14:12,250 CET DEBUG: Default library velocimacros.vtl not found. Trying old default library: VM_global_library.vm 2023-12-13 13:14:12,250 CET DEBUG: Old default library VM_global_library.vm not found. 2023-12-13 13:14:12,250 CET DEBUG: allowInline = true: VMs can be defined inline in templates 2023-12-13 13:14:12,250 CET DEBUG: allowInlineToOverride = false: VMs defined inline may NOT replace previous VM definitions 2023-12-13 13:14:12,250 CET DEBUG: allowInlineLocal = false: VMs defined inline will be global in scope if allowed. 2023-12-13 13:14:12,250 CET DEBUG: autoload off: VM system will not automatically reload global library macros 2023-12-13 13:14:12,250 CET INFO : using engine=Velocity2 <>, lang=Velocity2 Template Language <> for script: DependentScriptWithMacros 2023-12-13 13:14:12,446 CET DEBUG: added VM
[jira] [Updated] (VELOCITY-969) Lower scripts parser performance after update from 1.6 to 2.3 velocity version
[ https://issues.apache.org/jira/browse/VELOCITY-969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Magdalena Karpierz updated VELOCITY-969: Attachment: SampleScript.zip > Lower scripts parser performance after update from 1.6 to 2.3 velocity version > -- > > Key: VELOCITY-969 > URL: https://issues.apache.org/jira/browse/VELOCITY-969 > Project: Velocity > Issue Type: Bug >Reporter: Magdalena Karpierz >Priority: Critical > Attachments: SampleScript.zip > > > Hello Team, > > We have problems after update velocity 1.6.3 to 2.3 version with parsing > performance of the scripts which include many macros inside and overall > lenght of the script is about 3000 lines. > Performance execution of this kind of scripts decreased 10 times, example > script execution in velocity1 took: 1sec. and in velocity2: 6 to 10 seconds. > > Did You observe such performance issues? > Can You suggest us a potential solution for this problem? > > I prioritized this ticket as a critical, because our customers saw this > immediately and it blocks some further activities. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-969) Lower scripts parser performance after update from 1.6 to 2.3 velocity version
[ https://issues.apache.org/jira/browse/VELOCITY-969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794167#comment-17794167 ] Claude Brisson commented on VELOCITY-969: - We can potentially do something if we can reproduce the problem, or preferably if you can help us track down the origin of the regression by doing some profiling. > Lower scripts parser performance after update from 1.6 to 2.3 velocity version > -- > > Key: VELOCITY-969 > URL: https://issues.apache.org/jira/browse/VELOCITY-969 > Project: Velocity > Issue Type: Bug >Reporter: Magdalena Karpierz >Priority: Critical > > Hello Team, > > We have problems after update velocity 1.6.3 to 2.3 version with parsing > performance of the scripts which include many macros inside and overall > lenght of the script is about 3000 lines. > Performance execution of this kind of scripts decreased 10 times, example > script execution in velocity1 took: 1sec. and in velocity2: 6 to 10 seconds. > > Did You observe such performance issues? > Can You suggest us a potential solution for this problem? > > I prioritized this ticket as a critical, because our customers saw this > immediately and it blocks some further activities. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Created] (VELOCITY-969) Lower scripts parser performance after update from 1.6 to 2.3 velocity version
Magdalena Karpierz created VELOCITY-969: --- Summary: Lower scripts parser performance after update from 1.6 to 2.3 velocity version Key: VELOCITY-969 URL: https://issues.apache.org/jira/browse/VELOCITY-969 Project: Velocity Issue Type: Bug Reporter: Magdalena Karpierz Hello Team, We have problems after update velocity 1.6.3 to 2.3 version with parsing performance of the scripts which include many macros inside and overall lenght of the script is about 3000 lines. Performance execution of this kind of scripts decreased 10 times, example script execution in velocity1 took: 1sec. and in velocity2: 6 to 10 seconds. Did You observe such performance issues? Can You suggest us a potential solution for this problem? I prioritized this ticket as a critical, because our customers saw this immediately and it blocks some further activities. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-952) Velocity is calling the "wrong" method
[
https://issues.apache.org/jira/browse/VELOCITY-952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17772341#comment-17772341
]
Christopher Schultz commented on VELOCITY-952:
--
I reported this as VELOCITY-968 and offered the following as a suggestion. I
don't know how the introspector works, so I'm just waving my hands, here:
"
Maybe
org.apache.velocity.util.introspection.MethodMap.getBestMatch(List,
Class[]) can choose a superclass method over a subclass method if they are
otherwise equivalent?
"
I've read the documentation for MethodOverrideUberspector.java and I think if
you just always use the most-superclass-or-superinterface method available,
many of these issues can be avoided without any additional overhead of
remembering the return-type of certain "get" invocations. This will also help
when Velocity wasn't responsible for performing the original access, for
example when the object is just dropped into the context by Java code and has a
runtime type different from the declared type in the code.
> Velocity is calling the "wrong" method
> --
>
> Key: VELOCITY-952
> URL: https://issues.apache.org/jira/browse/VELOCITY-952
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Thomas Mortagne
>Priority: Major
>
> OK, the title is maybe a bit harsh, but it catches the eyes :)
> At XWiki we recently started testing on Java 17 to see if there is any
> problem which leaded us to add things like {{--add-opens
> java.base/java.util=ALL-UNNAMED}} but Velocity happen to be the source of
> another problem related to the new module world.
> When doing something like {{$datetool.timeZone.getOffset(0)}} ($datetool
> being the org.apache.velocity.tools.generic.DateTool) we get the following
> error:
> {noformat}
> ...
> Caused by: java.lang.IllegalAccessException: class
> org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl cannot
> access class sun.util.calendar.ZoneInfo (in module java.base) because module
> java.base does not export sun.util.calendar to unnamed module @7ca16adc
> at
> java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:392)
> at
> java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674)
> at java.base/java.lang.reflect.Method.invoke(Method.java:560)
> at
> org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:571)
> at
> org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:554)
> at
> org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:221)
> ... 199 more
> {noformat}
> The reason is that while the developer intent/expectation was to call
> "java.util.TimeZone#getOffset(0)" what Velocity really called from JVM point
> of view is "sun.util.calendar.ZoneInfo.getOffset(0)" directly.
> That's because Velocity is doing (I assume, since I did not check the exact
> code) the equivalent of:
> {noformat}
> java.util.TimeZone.getDefault().getClass().getMethod("getOffset",
> long.class).invoke(TimeZone.getDefault(), 0);
> {noformat}
> which is itself the equivalent of:
> {noformat}
> sun.util.calendar.ZoneInfo.class.getMethod("getOffset",
> long.class).invoke(TimeZone.getDefault(), 0);
> {noformat}
> I guess the only way to fix this would be to track down the lowest overridden
> Method (I agree, it might not always be easy to choose between two interfaces
> declaring a method with the same signature, but choosing the first one we
> find from the same hierarchy level is still better than nothing) and call
> that one instead. With the use case used as example in this issue, that would
> mean ending up doing the equivalent of:
> {noformat}
> java.util.TimeZone.class.getMethod("getOffset",
> long.class).invoke(TimeZone.getDefault(), 0);
> {noformat}
> which, from JVM point of view, is covered by the {{--add-opens
> java.base/java.util=ALL-UNNAMED}}.
> It would be a big change, but at least can't think of any retro-compatibility
> problem it might cause.
> One might be tempted to answer "just add {{--add-opens
> java.base/sun.util.calendar=ALL-UNNAMED}}" but it does not seem fair as this
> is not what the API that the script uses was exposing at all, you might need
> to document a different one for each JVM implementation (even if it's
> probably unlikely for this specific example) but more importantly you will
> potentially need quite a lot of
[jira] [Resolved] (VELOCITY-968) In Java 17+, introspection fails in many cases due to permissions
[
https://issues.apache.org/jira/browse/VELOCITY-968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Schultz resolved VELOCITY-968.
--
Resolution: Duplicate
Duplicate of VELOCITY-952
> In Java 17+, introspection fails in many cases due to permissions
> -
>
> Key: VELOCITY-968
> URL: https://issues.apache.org/jira/browse/VELOCITY-968
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 1.7.x, 2.3
> Environment: Java 17
>Reporter: Christopher Schultz
>Priority: Major
>
> When running under Java 17 or later, introspection often picks an
> inaccessible method on a runtime object, which then fails when invoked.
> For example, running the example below under Java 8, the output is simple:
> {noformat}
> Cert notAfter=Wed Jan 03 12:42:32 EST 2024
> Test: Wed Jan 03 12:42:32 EST 2024
> {noformat}
> When running on Java 11 or later, we get:
> {noformat}
> Cert notAfter=Wed Jan 03 12:42:32 EST 2024
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by
> org.apache.velocity.runtime.parser.node.PropertyExecutor
> (file:.../velocity-engine-core-2.3.jar) to method
> sun.security.x509.X509CertImpl.getNotAfter()
> WARNING: Please consider reporting this to the maintainers of
> org.apache.velocity.runtime.parser.node.PropertyExecutor
> WARNING: Use --illegal-access=warn to enable warnings of further illegal
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> Test: Wed Jan 03 12:42:32 EST 2024
> {noformat}
> When running on Java 17, we get:
> {noformat}
> Cert notAfter=Wed Jan 03 12:42:32 EST 2024
> Exception in thread "main" org.apache.velocity.exception.VelocityException:
> ASTIdentifier() : exception invoking method for identifier 'notAfter' in
> class sun.security.x509.X509CertImpl
> at
> org.apache.velocity.runtime.parser.node.ASTIdentifier.execute(ASTIdentifier.java:282)
> at
> org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:368)
> at
> org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:492)
> at
> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:439)
> at org.apache.velocity.Template.merge(Template.java:358)
> at org.apache.velocity.Template.merge(Template.java:262)
> at CertTest.main(CertTest.java:52)
> Caused by: java.lang.IllegalAccessException: class
> org.apache.velocity.runtime.parser.node.PropertyExecutor cannot access class
> sun.security.x509.X509CertImpl (in module java.base) because module java.base
> does not export sun.security.x509 to unnamed module @45ad6cad
> at
> java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:392)
> at
> java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674)
> at java.base/java.lang.reflect.Method.invoke(Method.java:560)
> at
> org.apache.velocity.runtime.parser.node.PropertyExecutor.execute(PropertyExecutor.java:149)
> at
> org.apache.velocity.util.introspection.UberspectImpl$VelGetterImpl.invoke(UberspectImpl.java:722)
> at
> org.apache.velocity.runtime.parser.node.ASTIdentifier.execute(ASTIdentifier.java:217)
> ... 6 more
> {noformat}
> It looks like Velocity is picking an inconvenient class on which to base its
> method invocation.
>
> Here is the test source.
> {noformat}
> import java.io.OutputStreamWriter;
> import java.io.StringReader;
> import java.nio.charset.StandardCharsets;
> import java.security.cert.Certificate;
> import java.security.cert.X509Certificate;
> import java.security.cert.CertificateFactory;
> import org.apache.velocity.Template;
> import org.apache.velocity.VelocityContext;
> import org.apache.velocity.app.VelocityEngine;
> import org.apache.velocity.runtime.RuntimeServices;
> import org.apache.velocity.runtime.RuntimeSingleton;
> public class CertTest {
> private static final String certText = "-BEGIN CERTIFICATE-\n"
> + "MIICJTCCAaygAwIBAgIIXjahgh5+v08wCgYIKoZIzj0EAwMwaTEQMA4GA1UEBhMH\n"
> + "VW5rbm93bjEQMA4GA1UECBMHVW5rbm93bjEQMA4GA1UEBxMHVW5rbm93bjEQMA4G\n"
> + "A1UEChMHVW5rbm93bjEQMA4GA1UECxMHVW5rbm93bjENMAsGA1UEAxMEdGVzdDAe\n"
> + "Fw0yMzEwMDUxNzQyMzJaFw0yNDAxMDMxNzQyMzJaMGkxEDAOBgNVBAYTB1Vua25v\n"
> + "d24xEDAOBgNVBAgTB1Vua25vd24xEDAOBgNVBAcTB1Vua25vd24xEDAOBgNVBAoT\n"
>
[jira] [Commented] (VELOCITY-968) In Java 17+, introspection fails in many cases due to permissions
[
https://issues.apache.org/jira/browse/VELOCITY-968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17772338#comment-17772338
]
Christopher Schultz commented on VELOCITY-968:
--
Yes, it does indeed look like a duplicate. Apologies. I did search, but the
description of VELOCITY-952 didn't seem to match and I didn't read the details.
> In Java 17+, introspection fails in many cases due to permissions
> -
>
> Key: VELOCITY-968
> URL: https://issues.apache.org/jira/browse/VELOCITY-968
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 1.7.x, 2.3
> Environment: Java 17
>Reporter: Christopher Schultz
>Priority: Major
>
> When running under Java 17 or later, introspection often picks an
> inaccessible method on a runtime object, which then fails when invoked.
> For example, running the example below under Java 8, the output is simple:
> {noformat}
> Cert notAfter=Wed Jan 03 12:42:32 EST 2024
> Test: Wed Jan 03 12:42:32 EST 2024
> {noformat}
> When running on Java 11 or later, we get:
> {noformat}
> Cert notAfter=Wed Jan 03 12:42:32 EST 2024
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by
> org.apache.velocity.runtime.parser.node.PropertyExecutor
> (file:.../velocity-engine-core-2.3.jar) to method
> sun.security.x509.X509CertImpl.getNotAfter()
> WARNING: Please consider reporting this to the maintainers of
> org.apache.velocity.runtime.parser.node.PropertyExecutor
> WARNING: Use --illegal-access=warn to enable warnings of further illegal
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> Test: Wed Jan 03 12:42:32 EST 2024
> {noformat}
> When running on Java 17, we get:
> {noformat}
> Cert notAfter=Wed Jan 03 12:42:32 EST 2024
> Exception in thread "main" org.apache.velocity.exception.VelocityException:
> ASTIdentifier() : exception invoking method for identifier 'notAfter' in
> class sun.security.x509.X509CertImpl
> at
> org.apache.velocity.runtime.parser.node.ASTIdentifier.execute(ASTIdentifier.java:282)
> at
> org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:368)
> at
> org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:492)
> at
> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:439)
> at org.apache.velocity.Template.merge(Template.java:358)
> at org.apache.velocity.Template.merge(Template.java:262)
> at CertTest.main(CertTest.java:52)
> Caused by: java.lang.IllegalAccessException: class
> org.apache.velocity.runtime.parser.node.PropertyExecutor cannot access class
> sun.security.x509.X509CertImpl (in module java.base) because module java.base
> does not export sun.security.x509 to unnamed module @45ad6cad
> at
> java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:392)
> at
> java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674)
> at java.base/java.lang.reflect.Method.invoke(Method.java:560)
> at
> org.apache.velocity.runtime.parser.node.PropertyExecutor.execute(PropertyExecutor.java:149)
> at
> org.apache.velocity.util.introspection.UberspectImpl$VelGetterImpl.invoke(UberspectImpl.java:722)
> at
> org.apache.velocity.runtime.parser.node.ASTIdentifier.execute(ASTIdentifier.java:217)
> ... 6 more
> {noformat}
> It looks like Velocity is picking an inconvenient class on which to base its
> method invocation.
>
> Here is the test source.
> {noformat}
> import java.io.OutputStreamWriter;
> import java.io.StringReader;
> import java.nio.charset.StandardCharsets;
> import java.security.cert.Certificate;
> import java.security.cert.X509Certificate;
> import java.security.cert.CertificateFactory;
> import org.apache.velocity.Template;
> import org.apache.velocity.VelocityContext;
> import org.apache.velocity.app.VelocityEngine;
> import org.apache.velocity.runtime.RuntimeServices;
> import org.apache.velocity.runtime.RuntimeSingleton;
> public class CertTest {
> private static final String certText = "-BEGIN CERTIFICATE-\n"
> + "MIICJTCCAaygAwIBAgIIXjahgh5+v08wCgYIKoZIzj0EAwMwaTEQMA4GA1UEBhMH\n"
> + "VW5rbm93bjEQMA4GA1UECBMHVW5rbm93bjEQMA4GA1UEBxMHVW5rbm93bjEQMA4G\n"
> + "A1UEChMHVW5rbm93bjEQMA4GA1UECxMHVW5rbm93bjENMAsGA1UEAxMEdGVzdDAe\n"
> + "Fw0yMzEwMDUxNzQyMzJaFw
[jira] [Comment Edited] (VELOCITY-968) In Java 17+, introspection fails in many cases due to permissions
[
https://issues.apache.org/jira/browse/VELOCITY-968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17772335#comment-17772335
]
Christopher Schultz edited comment on VELOCITY-968 at 10/5/23 6:28 PM:
---
Maybe
org.apache.velocity.util.introspection.MethodMap.getBestMatch(List,
Class[]) can choose a superclass method over a subclass method if they are
otherwise equivalent?
was (Author: ch...@christopherschultz.net):
Maybe
`org.apache.velocity.util.introspection.MethodMap.getBestMatch(List,
Class[])` can choose a superclass method over a subclass method if they are
otherwise equivalent?
> In Java 17+, introspection fails in many cases due to permissions
> -
>
> Key: VELOCITY-968
> URL: https://issues.apache.org/jira/browse/VELOCITY-968
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 1.7.x, 2.3
> Environment: Java 17
>Reporter: Christopher Schultz
>Priority: Major
>
> When running under Java 17 or later, introspection often picks an
> inaccessible method on a runtime object, which then fails when invoked.
> For example, running the example below under Java 8, the output is simple:
> {noformat}
> Cert notAfter=Wed Jan 03 12:42:32 EST 2024
> Test: Wed Jan 03 12:42:32 EST 2024
> {noformat}
> When running on Java 11 or later, we get:
> {noformat}
> Cert notAfter=Wed Jan 03 12:42:32 EST 2024
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by
> org.apache.velocity.runtime.parser.node.PropertyExecutor
> (file:.../velocity-engine-core-2.3.jar) to method
> sun.security.x509.X509CertImpl.getNotAfter()
> WARNING: Please consider reporting this to the maintainers of
> org.apache.velocity.runtime.parser.node.PropertyExecutor
> WARNING: Use --illegal-access=warn to enable warnings of further illegal
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> Test: Wed Jan 03 12:42:32 EST 2024
> {noformat}
> When running on Java 17, we get:
> {noformat}
> Cert notAfter=Wed Jan 03 12:42:32 EST 2024
> Exception in thread "main" org.apache.velocity.exception.VelocityException:
> ASTIdentifier() : exception invoking method for identifier 'notAfter' in
> class sun.security.x509.X509CertImpl
> at
> org.apache.velocity.runtime.parser.node.ASTIdentifier.execute(ASTIdentifier.java:282)
> at
> org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:368)
> at
> org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:492)
> at
> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:439)
> at org.apache.velocity.Template.merge(Template.java:358)
> at org.apache.velocity.Template.merge(Template.java:262)
> at CertTest.main(CertTest.java:52)
> Caused by: java.lang.IllegalAccessException: class
> org.apache.velocity.runtime.parser.node.PropertyExecutor cannot access class
> sun.security.x509.X509CertImpl (in module java.base) because module java.base
> does not export sun.security.x509 to unnamed module @45ad6cad
> at
> java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:392)
> at
> java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674)
> at java.base/java.lang.reflect.Method.invoke(Method.java:560)
> at
> org.apache.velocity.runtime.parser.node.PropertyExecutor.execute(PropertyExecutor.java:149)
> at
> org.apache.velocity.util.introspection.UberspectImpl$VelGetterImpl.invoke(UberspectImpl.java:722)
> at
> org.apache.velocity.runtime.parser.node.ASTIdentifier.execute(ASTIdentifier.java:217)
> ... 6 more
> {noformat}
> It looks like Velocity is picking an inconvenient class on which to base its
> method invocation.
>
> Here is the test source.
> {noformat}
> import java.io.OutputStreamWriter;
> import java.io.StringReader;
> import java.nio.charset.StandardCharsets;
> import java.security.cert.Certificate;
> import java.security.cert.X509Certificate;
> import java.security.cert.CertificateFactory;
> import org.apache.velocity.Template;
> import org.apache.velocity.VelocityContext;
> import org.apache.velocity.app.VelocityEngine;
> import org.apache.velocity.runtime.RuntimeServices;
> import org.apache.velocity.runtime.RuntimeSingleton;
> public class CertTest {
> private static final String certText = "-BEGIN CERTIFICATE-\n"
> + "MIICJTCC
[jira] [Commented] (VELOCITY-968) In Java 17+, introspection fails in many cases due to permissions
[
https://issues.apache.org/jira/browse/VELOCITY-968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17772335#comment-17772335
]
Christopher Schultz commented on VELOCITY-968:
--
Maybe
`org.apache.velocity.util.introspection.MethodMap.getBestMatch(List,
Class[])` can choose a superclass method over a subclass method if they are
otherwise equivalent?
> In Java 17+, introspection fails in many cases due to permissions
> -
>
> Key: VELOCITY-968
> URL: https://issues.apache.org/jira/browse/VELOCITY-968
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 1.7.x, 2.3
> Environment: Java 17
>Reporter: Christopher Schultz
>Priority: Major
>
> When running under Java 17 or later, introspection often picks an
> inaccessible method on a runtime object, which then fails when invoked.
> For example, running the example below under Java 8, the output is simple:
> {noformat}
> Cert notAfter=Wed Jan 03 12:42:32 EST 2024
> Test: Wed Jan 03 12:42:32 EST 2024
> {noformat}
> When running on Java 11 or later, we get:
> {noformat}
> Cert notAfter=Wed Jan 03 12:42:32 EST 2024
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by
> org.apache.velocity.runtime.parser.node.PropertyExecutor
> (file:.../velocity-engine-core-2.3.jar) to method
> sun.security.x509.X509CertImpl.getNotAfter()
> WARNING: Please consider reporting this to the maintainers of
> org.apache.velocity.runtime.parser.node.PropertyExecutor
> WARNING: Use --illegal-access=warn to enable warnings of further illegal
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> Test: Wed Jan 03 12:42:32 EST 2024
> {noformat}
> When running on Java 17, we get:
> {noformat}
> Cert notAfter=Wed Jan 03 12:42:32 EST 2024
> Exception in thread "main" org.apache.velocity.exception.VelocityException:
> ASTIdentifier() : exception invoking method for identifier 'notAfter' in
> class sun.security.x509.X509CertImpl
> at
> org.apache.velocity.runtime.parser.node.ASTIdentifier.execute(ASTIdentifier.java:282)
> at
> org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:368)
> at
> org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:492)
> at
> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:439)
> at org.apache.velocity.Template.merge(Template.java:358)
> at org.apache.velocity.Template.merge(Template.java:262)
> at CertTest.main(CertTest.java:52)
> Caused by: java.lang.IllegalAccessException: class
> org.apache.velocity.runtime.parser.node.PropertyExecutor cannot access class
> sun.security.x509.X509CertImpl (in module java.base) because module java.base
> does not export sun.security.x509 to unnamed module @45ad6cad
> at
> java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:392)
> at
> java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674)
> at java.base/java.lang.reflect.Method.invoke(Method.java:560)
> at
> org.apache.velocity.runtime.parser.node.PropertyExecutor.execute(PropertyExecutor.java:149)
> at
> org.apache.velocity.util.introspection.UberspectImpl$VelGetterImpl.invoke(UberspectImpl.java:722)
> at
> org.apache.velocity.runtime.parser.node.ASTIdentifier.execute(ASTIdentifier.java:217)
> ... 6 more
> {noformat}
> It looks like Velocity is picking an inconvenient class on which to base its
> method invocation.
>
> Here is the test source.
> {noformat}
> import java.io.OutputStreamWriter;
> import java.io.StringReader;
> import java.nio.charset.StandardCharsets;
> import java.security.cert.Certificate;
> import java.security.cert.X509Certificate;
> import java.security.cert.CertificateFactory;
> import org.apache.velocity.Template;
> import org.apache.velocity.VelocityContext;
> import org.apache.velocity.app.VelocityEngine;
> import org.apache.velocity.runtime.RuntimeServices;
> import org.apache.velocity.runtime.RuntimeSingleton;
> public class CertTest {
> private static final String certText = "-BEGIN CERTIFICATE-\n"
> + "MIICJTCCAaygAwIBAgIIXjahgh5+v08wCgYIKoZIzj0EAwMwaTEQMA4GA1UEBhMH\n"
> + "VW5rbm93bjEQMA4GA1UECBMHVW5rbm93bjEQMA4GA1UEBxMHVW5rbm93bjEQMA4G\n"
> + "A1UEChMHVW5rbm93bjEQMA4GA1UECxMHVW5rbm93bjENMAsGA1UEAxMEdGV
[jira] [Commented] (VELOCITY-968) In Java 17+, introspection fails in many cases due to permissions
[
https://issues.apache.org/jira/browse/VELOCITY-968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17772334#comment-17772334
]
Thomas Mortagne commented on VELOCITY-968:
--
Looks like a dupicate of VELOCITY-952.
> In Java 17+, introspection fails in many cases due to permissions
> -
>
> Key: VELOCITY-968
> URL: https://issues.apache.org/jira/browse/VELOCITY-968
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 1.7.x, 2.3
> Environment: Java 17
>Reporter: Christopher Schultz
>Priority: Major
>
> When running under Java 17 or later, introspection often picks an
> inaccessible method on a runtime object, which then fails when invoked.
> For example, running the example below under Java 8, the output is simple:
> {noformat}
> Cert notAfter=Wed Jan 03 12:42:32 EST 2024
> Test: Wed Jan 03 12:42:32 EST 2024
> {noformat}
> When running on Java 11 or later, we get:
> {noformat}
> Cert notAfter=Wed Jan 03 12:42:32 EST 2024
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by
> org.apache.velocity.runtime.parser.node.PropertyExecutor
> (file:.../velocity-engine-core-2.3.jar) to method
> sun.security.x509.X509CertImpl.getNotAfter()
> WARNING: Please consider reporting this to the maintainers of
> org.apache.velocity.runtime.parser.node.PropertyExecutor
> WARNING: Use --illegal-access=warn to enable warnings of further illegal
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> Test: Wed Jan 03 12:42:32 EST 2024
> {noformat}
> When running on Java 17, we get:
> {noformat}
> Cert notAfter=Wed Jan 03 12:42:32 EST 2024
> Exception in thread "main" org.apache.velocity.exception.VelocityException:
> ASTIdentifier() : exception invoking method for identifier 'notAfter' in
> class sun.security.x509.X509CertImpl
> at
> org.apache.velocity.runtime.parser.node.ASTIdentifier.execute(ASTIdentifier.java:282)
> at
> org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:368)
> at
> org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:492)
> at
> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:439)
> at org.apache.velocity.Template.merge(Template.java:358)
> at org.apache.velocity.Template.merge(Template.java:262)
> at CertTest.main(CertTest.java:52)
> Caused by: java.lang.IllegalAccessException: class
> org.apache.velocity.runtime.parser.node.PropertyExecutor cannot access class
> sun.security.x509.X509CertImpl (in module java.base) because module java.base
> does not export sun.security.x509 to unnamed module @45ad6cad
> at
> java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:392)
> at
> java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674)
> at java.base/java.lang.reflect.Method.invoke(Method.java:560)
> at
> org.apache.velocity.runtime.parser.node.PropertyExecutor.execute(PropertyExecutor.java:149)
> at
> org.apache.velocity.util.introspection.UberspectImpl$VelGetterImpl.invoke(UberspectImpl.java:722)
> at
> org.apache.velocity.runtime.parser.node.ASTIdentifier.execute(ASTIdentifier.java:217)
> ... 6 more
> {noformat}
> It looks like Velocity is picking an inconvenient class on which to base its
> method invocation.
>
> Here is the test source.
> {noformat}
> import java.io.OutputStreamWriter;
> import java.io.StringReader;
> import java.nio.charset.StandardCharsets;
> import java.security.cert.Certificate;
> import java.security.cert.X509Certificate;
> import java.security.cert.CertificateFactory;
> import org.apache.velocity.Template;
> import org.apache.velocity.VelocityContext;
> import org.apache.velocity.app.VelocityEngine;
> import org.apache.velocity.runtime.RuntimeServices;
> import org.apache.velocity.runtime.RuntimeSingleton;
> public class CertTest {
> private static final String certText = "-BEGIN CERTIFICATE-\n"
> + "MIICJTCCAaygAwIBAgIIXjahgh5+v08wCgYIKoZIzj0EAwMwaTEQMA4GA1UEBhMH\n"
> + "VW5rbm93bjEQMA4GA1UECBMHVW5rbm93bjEQMA4GA1UEBxMHVW5rbm93bjEQMA4G\n"
> + "A1UEChMHVW5rbm93bjEQMA4GA1UECxMHVW5rbm93bjENMAsGA1UEAxMEdGVzdDAe\n"
> + "Fw0yMzEwMDUxNzQyMzJaFw0yNDAxMDMxNzQyMzJaMGkxEDAOBgNVBAYTB1Vua25v\n"
> + "d24xEDAOBgNVBAgTB1Vua25vd24xEDAOB
[jira] [Updated] (VELOCITY-968) In Java 17+, introspection fails in many cases due to permissions
[
https://issues.apache.org/jira/browse/VELOCITY-968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Schultz updated VELOCITY-968:
-
Description:
When running under Java 17 or later, introspection often picks an inaccessible
method on a runtime object, which then fails when invoked.
For example, running the example below under Java 8, the output is simple:
{noformat}
Cert notAfter=Wed Jan 03 12:42:32 EST 2024
Test: Wed Jan 03 12:42:32 EST 2024
{noformat}
When running on Java 11 or later, we get:
{noformat}
Cert notAfter=Wed Jan 03 12:42:32 EST 2024
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by
org.apache.velocity.runtime.parser.node.PropertyExecutor
(file:.../velocity-engine-core-2.3.jar) to method
sun.security.x509.X509CertImpl.getNotAfter()
WARNING: Please consider reporting this to the maintainers of
org.apache.velocity.runtime.parser.node.PropertyExecutor
WARNING: Use --illegal-access=warn to enable warnings of further illegal
reflective access operations
WARNING: All illegal access operations will be denied in a future release
Test: Wed Jan 03 12:42:32 EST 2024
{noformat}
When running on Java 17, we get:
{noformat}
Cert notAfter=Wed Jan 03 12:42:32 EST 2024
Exception in thread "main" org.apache.velocity.exception.VelocityException:
ASTIdentifier() : exception invoking method for identifier 'notAfter' in class
sun.security.x509.X509CertImpl
at
org.apache.velocity.runtime.parser.node.ASTIdentifier.execute(ASTIdentifier.java:282)
at
org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:368)
at
org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:492)
at
org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:439)
at org.apache.velocity.Template.merge(Template.java:358)
at org.apache.velocity.Template.merge(Template.java:262)
at CertTest.main(CertTest.java:52)
Caused by: java.lang.IllegalAccessException: class
org.apache.velocity.runtime.parser.node.PropertyExecutor cannot access class
sun.security.x509.X509CertImpl (in module java.base) because module java.base
does not export sun.security.x509 to unnamed module @45ad6cad
at
java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:392)
at
java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674)
at java.base/java.lang.reflect.Method.invoke(Method.java:560)
at
org.apache.velocity.runtime.parser.node.PropertyExecutor.execute(PropertyExecutor.java:149)
at
org.apache.velocity.util.introspection.UberspectImpl$VelGetterImpl.invoke(UberspectImpl.java:722)
at
org.apache.velocity.runtime.parser.node.ASTIdentifier.execute(ASTIdentifier.java:217)
... 6 more
{noformat}
It looks like Velocity is picking an inconvenient class on which to base its
method invocation.
Here is the test source.
{noformat}
import java.io.OutputStreamWriter;
import java.io.StringReader;
import java.nio.charset.StandardCharsets;
import java.security.cert.Certificate;
import java.security.cert.X509Certificate;
import java.security.cert.CertificateFactory;
import org.apache.velocity.Template;
import org.apache.velocity.VelocityContext;
import org.apache.velocity.app.VelocityEngine;
import org.apache.velocity.runtime.RuntimeServices;
import org.apache.velocity.runtime.RuntimeSingleton;
public class CertTest {
private static final String certText = "-BEGIN CERTIFICATE-\n"
+ "MIICJTCCAaygAwIBAgIIXjahgh5+v08wCgYIKoZIzj0EAwMwaTEQMA4GA1UEBhMH\n"
+ "VW5rbm93bjEQMA4GA1UECBMHVW5rbm93bjEQMA4GA1UEBxMHVW5rbm93bjEQMA4G\n"
+ "A1UEChMHVW5rbm93bjEQMA4GA1UECxMHVW5rbm93bjENMAsGA1UEAxMEdGVzdDAe\n"
+ "Fw0yMzEwMDUxNzQyMzJaFw0yNDAxMDMxNzQyMzJaMGkxEDAOBgNVBAYTB1Vua25v\n"
+ "d24xEDAOBgNVBAgTB1Vua25vd24xEDAOBgNVBAcTB1Vua25vd24xEDAOBgNVBAoT\n"
+ "B1Vua25vd24xEDAOBgNVBAsTB1Vua25vd24xDTALBgNVBAMTBHRlc3QwdjAQBgcq\n"
+ "hkjOPQIBBgUrgQQAIgNiAARluamNquFohhtrjhN6Sq+QXVlb+/1GVHg0h10iDehm\n"
+ "msRkfPkugLIwRbLIaggzFkx66QcT4oIjhvM0Q1jM7a/9BhNUWJvZMa54M3Nh+K6P\n"
+ "fzp8tOGHe2EAHibDP1KSGHCjITAfMB0GA1UdDgQWBBSLy96Os2mUo7TiKAwRlEmq\n"
+ "dzOrCDAKBggqhkjOPQQDAwNnADBkAjBx+sqV2gzUusdOvwltH7f7sp5UtZMRFKF4\n"
+ "mRcGA7buAZN/YPUGgkiUZ6ZEJmw8Dn8CMEEgm8c2WTYdO/CQ5DRBbfIt1TcpiDxk\n"
+ "0vM+YZrSctwCJhK+3h3i4X990XvjJQ3Hmw==\n"
+ "-END CERTIFICATE-\n"
;
private static final String templateText = "Test: $cert.notAfter\n";
public static void main(String[] args) throws Exception {
X509Certificate cert =
(X509Certificate)CertificateFactory.getInstance("X.509").generateCertificate(new
java.io.ByteArrayInputStream(certText.getBytes(StandardCharsets.US_ASCII
[jira] [Created] (VELOCITY-968) In Java 17+, introspection fails in many cases due to permissions
Christopher Schultz created VELOCITY-968:
Summary: In Java 17+, introspection fails in many cases due to
permissions
Key: VELOCITY-968
URL: https://issues.apache.org/jira/browse/VELOCITY-968
Project: Velocity
Issue Type: Bug
Components: Engine
Affects Versions: 2.3, 1.7.x
Environment: Java 17
Reporter: Christopher Schultz
When running under Java 17 or later, introspection often picks an inaccessible
method on a runtime object, which then fails when invoked.
For example, running the example below under Java 8, the output is simple:
{noformat}
Cert notAfter=Wed Jan 03 12:42:32 EST 2024
Test: Wed Jan 03 12:42:32 EST 2024
{noformat}
When running on Java 11 or later, we get:
{noformat}
Cert notAfter=Wed Jan 03 12:42:32 EST 2024
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by
org.apache.velocity.runtime.parser.node.PropertyExecutor
(file:/Users/christopherschultz/Documents/Eclipse/chadis-web/velocity-engine-core-2.3.jar)
to method sun.security.x509.X509CertImpl.getNotAfter()
WARNING: Please consider reporting this to the maintainers of
org.apache.velocity.runtime.parser.node.PropertyExecutor
WARNING: Use --illegal-access=warn to enable warnings of further illegal
reflective access operations
WARNING: All illegal access operations will be denied in a future release
Test: Wed Jan 03 12:42:32 EST 2024
{noformat}
When running on Java 17, we get:
{noformat}
Cert notAfter=Wed Jan 03 12:42:32 EST 2024
Exception in thread "main" org.apache.velocity.exception.VelocityException:
ASTIdentifier() : exception invoking method for identifier 'notAfter' in class
sun.security.x509.X509CertImpl
at
org.apache.velocity.runtime.parser.node.ASTIdentifier.execute(ASTIdentifier.java:282)
at
org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:368)
at
org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:492)
at
org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:439)
at org.apache.velocity.Template.merge(Template.java:358)
at org.apache.velocity.Template.merge(Template.java:262)
at CertTest.main(CertTest.java:52)
Caused by: java.lang.IllegalAccessException: class
org.apache.velocity.runtime.parser.node.PropertyExecutor cannot access class
sun.security.x509.X509CertImpl (in module java.base) because module java.base
does not export sun.security.x509 to unnamed module @45ad6cad
at
java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:392)
at
java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674)
at java.base/java.lang.reflect.Method.invoke(Method.java:560)
at
org.apache.velocity.runtime.parser.node.PropertyExecutor.execute(PropertyExecutor.java:149)
at
org.apache.velocity.util.introspection.UberspectImpl$VelGetterImpl.invoke(UberspectImpl.java:722)
at
org.apache.velocity.runtime.parser.node.ASTIdentifier.execute(ASTIdentifier.java:217)
... 6 more
{noformat}
It looks like Velocity is picking an inconvenient class on which to base its
method invocation.
Here is the test source.
{noformat}
import java.io.OutputStreamWriter;
import java.io.StringReader;
import java.nio.charset.StandardCharsets;
import java.security.cert.Certificate;
import java.security.cert.X509Certificate;
import java.security.cert.CertificateFactory;
import org.apache.velocity.Template;
import org.apache.velocity.VelocityContext;
import org.apache.velocity.app.VelocityEngine;
import org.apache.velocity.runtime.RuntimeServices;
import org.apache.velocity.runtime.RuntimeSingleton;
public class CertTest {
private static final String certText = "-BEGIN CERTIFICATE-\n"
+ "MIICJTCCAaygAwIBAgIIXjahgh5+v08wCgYIKoZIzj0EAwMwaTEQMA4GA1UEBhMH\n"
+ "VW5rbm93bjEQMA4GA1UECBMHVW5rbm93bjEQMA4GA1UEBxMHVW5rbm93bjEQMA4G\n"
+ "A1UEChMHVW5rbm93bjEQMA4GA1UECxMHVW5rbm93bjENMAsGA1UEAxMEdGVzdDAe\n"
+ "Fw0yMzEwMDUxNzQyMzJaFw0yNDAxMDMxNzQyMzJaMGkxEDAOBgNVBAYTB1Vua25v\n"
+ "d24xEDAOBgNVBAgTB1Vua25vd24xEDAOBgNVBAcTB1Vua25vd24xEDAOBgNVBAoT\n"
+ "B1Vua25vd24xEDAOBgNVBAsTB1Vua25vd24xDTALBgNVBAMTBHRlc3QwdjAQBgcq\n"
+ "hkjOPQIBBgUrgQQAIgNiAARluamNquFohhtrjhN6Sq+QXVlb+/1GVHg0h10iDehm\n"
+ "msRkfPkugLIwRbLIaggzFkx66QcT4oIjhvM0Q1jM7a/9BhNUWJvZMa54M3Nh+K6P\n"
+ "fzp8tOGHe2EAHibDP1KSGHCjITAfMB0GA1UdDgQWBBSLy96Os2mUo7TiKAwRlEmq\n"
+ "dzOrCDAKBggqhkjOPQQDAwNnADBkAjBx+sqV2gzUusdOvwltH7f7sp5UtZMRFKF4\n"
+ "mRcGA7buAZN/YPUGgkiUZ6ZEJmw8Dn8CMEEgm8c2WTYdO/CQ5DRBbfIt1TcpiDxk\n"
+ "0vM+YZrSctwCJhK+3h3i4X990XvjJQ3Hmw==\n"
+ "-END CERTIFICATE-\n"
;
private static final Str
[jira] [Updated] (VELOCITY-967) Allows passing a list of Template instances to Template#merge
[
https://issues.apache.org/jira/browse/VELOCITY-967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mortagne updated VELOCITY-967:
-
Description:
Instead of the list of template names.
In [XWiki|https://www.xwiki.org] it's possible to define Velocity macros in all
kind of locations (files, pages, attachment in a page, object fields, etc.),
they can include each other but more importantly you can have several Velocity
scripts in the same page (or a page which included several other pages and now
has several scripts) with one of the scripts reusing macros defined in a
previous one.
So far, it was not too much of a problem, I just kept reusing the same Template
instance:
{code}
currentTemplate.setResourceLoader(new SingletonResourceReader(script));
currentTemplate.process();
currentTemplate.merge(context, out);
{code}
repeat...
But I'm starting to work on caching compiled Velocity (i.e. {{Template}}
instances) and execute them later in various different contexts. It's not a
problem for variables since they are stored in the context, but there is still
a problem for which I don't have a clean solution: passing current macros
(gathered from previous executed templates) to the currently executed one. I
first thought I could just call VelocityContext#setMacroLibraries before
template.merge(mergeContext, out); but unfortunately, merge "breaks" the
current context (it replaces the context macro libraries by an empty list) and
using template.merge(mergeContext, out, names); and a custom ResourceManager
would add too much complexity for various use cases.
My current workaround is to pass a custom Velocity context which overwrite
setMacroLibraries and ignore any call with an empty list as parameters (yeah,
not a huge fan either).
The simplest for us would be to pass directly the macro libraries Template
instances to Template#merge (to be perfectly honest, passing just the macros is
our real need but passing a Template list is more generic and in line with what
Template#merge is already doing in practice).
My plan is to write a (very easy) pull request, but I wanted to discuss the
idea first to see how well it's received.
was:
Instead of the list of template names.
In [XWiki|https://www.xwiki.org] it's possible to define Velocity macros in all
kind of locations (files, pages, attachment in a page, object fields, etc.),
they can include each other but more importantly you can have several Velocity
scripts in the same page (or a page which included several other pages and now
has several scripts) with one of the scripts reusing macros defined in a
previous one.
So far, it was not too much of a problem, I just kept reusing the same Template
instance:
{code}
currentTemplate.setResourceLoader(new SingletonResourceReader(script));
currentTemplate.process();
currentTemplate.merge(context, out);
{code}
repeat...
But I'm starting to work on caching compiled Velocity (i.e. {{Template}}
instances) and execute them later in various different contexts. It's not a
problem for variables since they are stored in the context, but there is still
a problem for which I don't have a clean solution: passing current macros
(gathered from previous executed templates) to the currently executed one. I
first thought I could just call VelocityContext#setMacroLibraries before
template.merge(mergeContext, out); but unfortunately, merge "breaks" the
current context (it replaces the context macro libraries by an empty list) and
using template.merge(mergeContext, out, names); and a custom ResourceManager
would add too much complexity for various use cases.
My current workaround is to pass a custom Velocity context which overwrite
setMacroLibraries and ignore any call with an empty list as parameters (yeah,
not a huge fan either).
The simplest for us would be to pass directly the macro libraries Template
instances of Template#merge (to be perfectly honest, passing just the macros is
our real need but passing a Template list is more generic and in line with what
Template#merge is already doing in practice).
My plan is to write a (very easy) pull request, but I wanted to discuss the
idea first to see how well it's received.
> Allows passing a list of Template instances to Template#merge
> -
>
> Key: VELOCITY-967
> URL: https://issues.apache.org/jira/browse/VELOCITY-967
> Project: Velocity
> Issue Type: Improvement
> Components: Engine
>Affects Versions: 2.3
>Reporter: Thomas Mortagne
>Priority: Major
>
> Instead of the list of template names.
> In [XWiki|https://www.xwiki.org] it's possible to define Velocity macros in
> all kind of locations (files, pages, attachment in a page, object fields,
>
[jira] [Updated] (VELOCITY-967) Allows passing a list of Template instances to Template#merge
[
https://issues.apache.org/jira/browse/VELOCITY-967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mortagne updated VELOCITY-967:
-
Description:
Instead of the list of template names.
In [XWiki|https://www.xwiki.org] it's possible to define Velocity macros in all
kind of locations (files, pages, attachment in a page, object fields, etc.),
they can include each other but more importantly you can have several Velocity
scripts in the same page (or a page which included several other pages and now
has several scripts) with one of the scripts reusing macros defined in a
previous one.
So far, it was not too much of a problem, I just kept reusing the same Template
instance:
{code}
currentTemplate.setResourceLoader(new SingletonResourceReader(script));
currentTemplate.process();
currentTemplate.merge(context, out);
{code}
repeat...
But I'm starting to work on caching compiled Velocity (i.e. {{Template}}
instances) and execute them later in various different contexts. It's not a
problem for variables since they are stored in the context, but there is still
a problem for which I don't have a clean solution: passing current macros
(gathered from previous executed templates) to the currently executed one. I
first thought I could just call VelocityContext#setMacroLibraries before
template.merge(mergeContext, out); but unfortunately, merge "breaks" the
current context (it replaces the context macro libraries by an empty list) and
using template.merge(mergeContext, out, names); and a custom ResourceManager
would add too much complexity for various use cases.
My current workaround is to pass a custom Velocity context which overwrite
setMacroLibraries and ignore any call with an empty list as parameters (yeah,
not a huge fan either).
The simplest for us would be to pass directly the macro libraries Template
instances of Template#merge (to be perfectly honest, passing just the macros is
our real need but passing a Template list is more generic and in line with what
Template#merge is already doing in practice).
My plan is to write a (very easy) pull request, but I wanted to discuss the
idea first to see how well it's received.
was:
Instead of the list of template names.
In [XWiki|https://www.xwiki.org] it's possible to define Velocity macros in all
kind of locations (files, pages, attachment in a page, object fields, etc.),
they can include each other but more importantly you can have several Velocity
scripts in the same page (or a page which included several other pages and now
has several scripts) with one of the scripts reusing macros defined in a
previous one.
So far, it was not too much of a problem, I just kept reusing the same Template
instance:
{{code}}
currentTemplate.setResourceLoader(new SingletonResourceReader(script));
currentTemplate.process();
currentTemplate.merge(context, out);
{{code}}
repeat...
But I'm starting to work on caching compiled Velocity (i.e. {{Template}}
instances) and execute them later in various different contexts. It's not a
problem for variables since they are stored in the context, but there is still
a problem for which I don't have a clean solution: passing current macros
(gathered from previous executed templates) to the currently executed one. I
first thought I could just call VelocityContext#setMacroLibraries before
template.merge(mergeContext, out); but unfortunately, merge "breaks" the
current context (it replaces the context macro libraries by an empty list) and
using template.merge(mergeContext, out, names); and a custom ResourceManager
would add too much complexity for various use cases.
My current workaround is to pass a custom Velocity context which overwrite
setMacroLibraries and ignore any call with an empty list as parameters (yeah,
not a huge fan either).
The simplest for us would be to pass directly the macro libraries Template
instances of Template#merge (to be perfectly honest, passing just the macros is
our real need but passing a Template list is more generic and in line with what
Template#merge is already doing in practice).
My plan is to write a (very easy) pull request, but I wanted to discuss the
idea first to see how well it's received.
> Allows passing a list of Template instances to Template#merge
> -
>
> Key: VELOCITY-967
> URL: https://issues.apache.org/jira/browse/VELOCITY-967
> Project: Velocity
> Issue Type: Improvement
> Components: Engine
>Affects Versions: 2.3
>Reporter: Thomas Mortagne
>Priority: Major
>
> Instead of the list of template names.
> In [XWiki|https://www.xwiki.org] it's possible to define Velocity macros in
> all kind of locations (files, pages, attachment in a page, object fields,
[jira] [Created] (VELOCITY-967) Allows passing a list of Template instances to Template#merge
Thomas Mortagne created VELOCITY-967:
Summary: Allows passing a list of Template instances to
Template#merge
Key: VELOCITY-967
URL: https://issues.apache.org/jira/browse/VELOCITY-967
Project: Velocity
Issue Type: Improvement
Components: Engine
Affects Versions: 2.3
Reporter: Thomas Mortagne
Instead of the list of template names.
In [XWiki|https://www.xwiki.org] it's possible to define Velocity macros in all
kind of locations (files, pages, attachment in a page, object fields, etc.),
they can include each other but more importantly you can have several Velocity
scripts in the same page (or a page which included several other pages and now
has several scripts) with one of the scripts reusing macros defined in a
previous one.
So far, it was not too much of a problem, I just kept reusing the same Template
instance:
{{code}}
currentTemplate.setResourceLoader(new SingletonResourceReader(script));
currentTemplate.process();
currentTemplate.merge(context, out);
{{code}}
repeat...
But I'm starting to work on caching compiled Velocity (i.e. {{Template}}
instances) and execute them later in various different contexts. It's not a
problem for variables since they are stored in the context, but there is still
a problem for which I don't have a clean solution: passing current macros
(gathered from previous executed templates) to the currently executed one. I
first thought I could just call VelocityContext#setMacroLibraries before
template.merge(mergeContext, out); but unfortunately, merge "breaks" the
current context (it replaces the context macro libraries by an empty list) and
using template.merge(mergeContext, out, names); and a custom ResourceManager
would add too much complexity for various use cases.
My current workaround is to pass a custom Velocity context which overwrite
setMacroLibraries and ignore any call with an empty list as parameters (yeah,
not a huge fan either).
The simplest for us would be to pass directly the macro libraries Template
instances of Template#merge (to be perfectly honest, passing just the macros is
our real need but passing a Template list is more generic and in line with what
Template#merge is already doing in practice).
My plan is to write a (very easy) pull request, but I wanted to discuss the
idea first to see how well it's received.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-367) Anakia throws NullPointerException if run under Maven with Custom Contexts
[ https://issues.apache.org/jira/browse/VELOCITY-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Wells updated VELOCITY-367: - Reporter: Henning Schmiedehausen (was: Henning Schmiedehausen) > Anakia throws NullPointerException if run under Maven with Custom Contexts > -- > > Key: VELOCITY-367 > URL: https://issues.apache.org/jira/browse/VELOCITY-367 > Project: Velocity > Issue Type: Bug > Components: Anakia >Affects Versions: 1.5 > Environment: Operating System: Linux > Platform: All >Reporter: Henning Schmiedehausen >Priority: Major > Attachments: ASF.LICENSE.NOT.GRANTED--anakia.patch > > > The AnakiaTask has the feature to use a custom context object. This is tested > in > the AnakiaTestCase. However, when running this test (and the AnakiaTask) under > Maven, it fails with a NullPointerException. The reason is that maven uses a > different sequence to initialize the AnakiaTask and Context objects and set > their properties. When running under ant, the setFile() method in the Context > object is called after setBaseDir() in the AnakiaTask, which allows setFile() > to > resolve the baseDir member. When running under maven, setBasedir() is called > after the Context object has been initialized thus using a null baseDir > element > when creating the contextFile element in Context. > When using an element outside the current working directory, this leads to > subContext.getContextDocument() returning null in line 378, thus resulting in > a > NullPointerException. > The attached patch adds checks for this condition and throws a BuildExeption. > It > also defers the creation of the contextDoc member of the context until it is > actually referenced. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-966) RuntimeInstance.render throws null pointer exception when trying to render the same AST
[
https://issues.apache.org/jira/browse/VELOCITY-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex updated VELOCITY-966:
--
Description:
The objective is to use
*RuntimeInstance.parse* to get the parsed AST for some template and cache the
AST.
Then use *RuntimeInstance.render* multiple times to render the text.
It appears that in version 2.3 {*}RuntimeInstance.{*}{*}render{*} invokes the
Node.init call and at the end of the rendering clears the parser and tokens. On
the next attempt to render init fails with the NullPointerException because
tokens have been cleared.{*}{*}
So you can not call *RuntimeInstance.render* on the same AST several times
which seems to be the intent of this method...
was:
The objective is to use
*RuntimeInstance.parse* to get the parsed AST for some test and cache the AST.
Then use *RuntimeInstance.render* multiple times to render the text.
It appears that in version 2.3 {*}RuntimeInstance.{*}{*}render{*} invokes the
Node.init call and at the end of the rendering clears the parser and tokens. On
the next attempt to render init fails with the NullPointerException because
tokens have been cleared.{*}{*}
So you can not call *RuntimeInstance.render* on the same AST several times
which seems to be the intent of this method...
> RuntimeInstance.render throws null pointer exception when trying to render
> the same AST
>
>
> Key: VELOCITY-966
> URL: https://issues.apache.org/jira/browse/VELOCITY-966
> Project: Velocity
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Alex
>Priority: Major
>
> The objective is to use
> *RuntimeInstance.parse* to get the parsed AST for some template and cache the
> AST.
> Then use *RuntimeInstance.render* multiple times to render the text.
>
> It appears that in version 2.3 {*}RuntimeInstance.{*}{*}render{*} invokes the
> Node.init call and at the end of the rendering clears the parser and tokens.
> On the next attempt to render init fails with the NullPointerException
> because tokens have been cleared.{*}{*}
>
> So you can not call *RuntimeInstance.render* on the same AST several times
> which seems to be the intent of this method...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-966) RuntimeInstance.render throws null pointer exception when trying to render the same AST
[
https://issues.apache.org/jira/browse/VELOCITY-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex updated VELOCITY-966:
--
Affects Version/s: 2.3
Description:
The objective is to use
*RuntimeInstance.parse* to get the parsed AST for some test and cache the AST.
Then use *RuntimeInstance.render* multiple times to render the text.
It appears that in version 2.3 {*}RuntimeInstance.{*}{*}render{*} invokes the
Node.init call and at the end of the rendering clears the parser and tokens. On
the next attempt to render init fails with the NullPointerException because
tokens have been cleared.{*}{*}
So you can not call *RuntimeInstance.render* on the same AST several times
which seems to be the intent of this method...
> RuntimeInstance.render throws null pointer exception when trying to render
> the same AST
>
>
> Key: VELOCITY-966
> URL: https://issues.apache.org/jira/browse/VELOCITY-966
> Project: Velocity
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Alex
>Priority: Major
>
> The objective is to use
> *RuntimeInstance.parse* to get the parsed AST for some test and cache the AST.
> Then use *RuntimeInstance.render* multiple times to render the text.
>
> It appears that in version 2.3 {*}RuntimeInstance.{*}{*}render{*} invokes the
> Node.init call and at the end of the rendering clears the parser and tokens.
> On the next attempt to render init fails with the NullPointerException
> because tokens have been cleared.{*}{*}
>
> So you can not call *RuntimeInstance.render* on the same AST several times
> which seems to be the intent of this method...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Created] (VELOCITY-966) RuntimeInstance.render throws null pointer exception when trying to render the same AST
Alex created VELOCITY-966: - Summary: RuntimeInstance.render throws null pointer exception when trying to render the same AST Key: VELOCITY-966 URL: https://issues.apache.org/jira/browse/VELOCITY-966 Project: Velocity Issue Type: Bug Reporter: Alex -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Moved] (VELTOOLS-202) VelocityViewServlet extending from jakarta.servlet instead of javax.servlet
[ https://issues.apache.org/jira/browse/VELTOOLS-202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov moved VELOCITY-942 to VELTOOLS-202: -- Component/s: VelocityView (was: Engine) Key: VELTOOLS-202 (was: VELOCITY-942) Project: Velocity Tools (was: Velocity) > VelocityViewServlet extending from jakarta.servlet instead of javax.servlet > --- > > Key: VELTOOLS-202 > URL: https://issues.apache.org/jira/browse/VELTOOLS-202 > Project: Velocity Tools > Issue Type: New Feature > Components: VelocityView >Reporter: David Ruiz de Azua >Priority: Trivial > > To whom may concern, > Currently VelocityViewServlet extends from javax rather than jakarta. > Due the cutover from Java to Jakarta, *is there any plan to make Apache > Velocity compatible with Servlet 5.0?* > Not sure if there are any plans to make the transition to Jakarta namespace > and if there is any ETA for it. > [https://jakarta.ee/specifications/servlet/5.0/apidocs/jakarta/servlet/http/httpservlet] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-965) Velocity 1.7 vs velocity 2.3: Getting thread synchronization issue
[
https://issues.apache.org/jira/browse/VELOCITY-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17725811#comment-17725811
]
Marinó A. Jónsson commented on VELOCITY-965:
* There is no need to share the Statement for fetching the timestamp as it just
returns a value and not a Reader - so this particular error is easily fixed
(the readLastModified method isn't even synchronized).
* However, according to the stackoverflow discussion it seems that if the same
Statement is executed twice the second query will close the previous ResultSet
- so this implementation is not thread-safe even though the getResourceReader
method is synchronized ... if two templates are being fetched at the same time
the second query could easily close the first ResultSet for the first query
before the Reader has finished reading.
> Velocity 1.7 vs velocity 2.3: Getting thread synchronization issue
> --
>
> Key: VELOCITY-965
> URL: https://issues.apache.org/jira/browse/VELOCITY-965
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Amrit
>Priority: Major
>
> Recently we migrated from Velocity 1.7 to Velocity 2.3. We see the below
> error intermittently which is a possible thread synchronization issue with
> Velocity Engine. The resultset is getting closed while another thread is
> making use of it.
> {noformat}
> 2023-04-15 10:36:33.472 ERROR [org.apache.velocity.loader.ds]
> {344} - DataSourceResourceLoader: database problem while getting timestamp of
> 'xyz_abc':
> java.sql.SQLException: Closed Resultset: next
> at
> oracle.jdbc.driver.InsensitiveScrollableResultSet.ensureOpen(InsensitiveScrollableResultSet.java:109)
> ~[ojdbc8.jar:12.2.0.1.0]
> at
> oracle.jdbc.driver.InsensitiveScrollableResultSet.next(InsensitiveScrollableResultSet.java:398)
> ~[ojdbc8.jar:12.2.0.1.0]
> at
> weblogic.jdbc.wrapper.ResultSet_oracle_jdbc_driver_ForwardOnlyResultSet.next(Unknown
> Source) ~[CodeGenerator.class:12.2.1.3]
> at
> org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader.readLastModified(DataSourceResourceLoader.java:326)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader.getLastModified(DataSourceResourceLoader.java:240)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:446)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:346)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1677)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1656)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.app.VelocityEngine.getTemplate(VelocityEngine.java:314)
> ~[velocity-engine-core-2.3.jar:2.3]
> {noformat}
> Reference:
> https://stackoverflow.com/questions/2794167/is-resultset-thread-safe
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-965) Velocity 1.7 vs velocity 2.3: Getting thread synchronization issue
[
https://issues.apache.org/jira/browse/VELOCITY-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17725784#comment-17725784
]
Marinó A. Jónsson commented on VELOCITY-965:
PR is a "Pull Request" for the git repository (see
[https://github.com/apache/velocity-engine]) ... if you clone the project and
fix the issue yourself, you can put it in a separate branch, push it to the git
repository, and then create a pull request for it to be merged with the master
branch.
> Velocity 1.7 vs velocity 2.3: Getting thread synchronization issue
> --
>
> Key: VELOCITY-965
> URL: https://issues.apache.org/jira/browse/VELOCITY-965
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Amrit
>Priority: Major
>
> Recently we migrated from Velocity 1.7 to Velocity 2.3. We see the below
> error intermittently which is a possible thread synchronization issue with
> Velocity Engine. The resultset is getting closed while another thread is
> making use of it.
> {noformat}
> 2023-04-15 10:36:33.472 ERROR [org.apache.velocity.loader.ds]
> {344} - DataSourceResourceLoader: database problem while getting timestamp of
> 'xyz_abc':
> java.sql.SQLException: Closed Resultset: next
> at
> oracle.jdbc.driver.InsensitiveScrollableResultSet.ensureOpen(InsensitiveScrollableResultSet.java:109)
> ~[ojdbc8.jar:12.2.0.1.0]
> at
> oracle.jdbc.driver.InsensitiveScrollableResultSet.next(InsensitiveScrollableResultSet.java:398)
> ~[ojdbc8.jar:12.2.0.1.0]
> at
> weblogic.jdbc.wrapper.ResultSet_oracle_jdbc_driver_ForwardOnlyResultSet.next(Unknown
> Source) ~[CodeGenerator.class:12.2.1.3]
> at
> org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader.readLastModified(DataSourceResourceLoader.java:326)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader.getLastModified(DataSourceResourceLoader.java:240)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:446)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:346)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1677)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1656)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.app.VelocityEngine.getTemplate(VelocityEngine.java:314)
> ~[velocity-engine-core-2.3.jar:2.3]
> {noformat}
> Reference:
> https://stackoverflow.com/questions/2794167/is-resultset-thread-safe
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-965) Velocity 1.7 vs velocity 2.3: Getting thread synchronization issue
[
https://issues.apache.org/jira/browse/VELOCITY-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17725755#comment-17725755
]
Amrit commented on VELOCITY-965:
Thanks for the comment. Sorry what do you mean by PR here?
> Velocity 1.7 vs velocity 2.3: Getting thread synchronization issue
> --
>
> Key: VELOCITY-965
> URL: https://issues.apache.org/jira/browse/VELOCITY-965
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Amrit
>Priority: Major
>
> Recently we migrated from Velocity 1.7 to Velocity 2.3. We see the below
> error intermittently which is a possible thread synchronization issue with
> Velocity Engine. The resultset is getting closed while another thread is
> making use of it.
> {noformat}
> 2023-04-15 10:36:33.472 ERROR [org.apache.velocity.loader.ds]
> {344} - DataSourceResourceLoader: database problem while getting timestamp of
> 'xyz_abc':
> java.sql.SQLException: Closed Resultset: next
> at
> oracle.jdbc.driver.InsensitiveScrollableResultSet.ensureOpen(InsensitiveScrollableResultSet.java:109)
> ~[ojdbc8.jar:12.2.0.1.0]
> at
> oracle.jdbc.driver.InsensitiveScrollableResultSet.next(InsensitiveScrollableResultSet.java:398)
> ~[ojdbc8.jar:12.2.0.1.0]
> at
> weblogic.jdbc.wrapper.ResultSet_oracle_jdbc_driver_ForwardOnlyResultSet.next(Unknown
> Source) ~[CodeGenerator.class:12.2.1.3]
> at
> org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader.readLastModified(DataSourceResourceLoader.java:326)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader.getLastModified(DataSourceResourceLoader.java:240)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:446)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:346)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1677)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1656)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.app.VelocityEngine.getTemplate(VelocityEngine.java:314)
> ~[velocity-engine-core-2.3.jar:2.3]
> {noformat}
> Reference:
> https://stackoverflow.com/questions/2794167/is-resultset-thread-safe
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-965) Velocity 1.7 vs velocity 2.3: Getting thread synchronization issue
[
https://issues.apache.org/jira/browse/VELOCITY-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17725744#comment-17725744
]
Michael Osipov commented on VELOCITY-965:
-
This is open source, you can provide a PR to address the issue. Moreover, you
cannot expect anything since this is open source. If you want progress, do
something.
> Velocity 1.7 vs velocity 2.3: Getting thread synchronization issue
> --
>
> Key: VELOCITY-965
> URL: https://issues.apache.org/jira/browse/VELOCITY-965
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Amrit
>Priority: Major
>
> Recently we migrated from Velocity 1.7 to Velocity 2.3. We see the below
> error intermittently which is a possible thread synchronization issue with
> Velocity Engine. The resultset is getting closed while another thread is
> making use of it.
> {noformat}
> 2023-04-15 10:36:33.472 ERROR [org.apache.velocity.loader.ds]
> {344} - DataSourceResourceLoader: database problem while getting timestamp of
> 'xyz_abc':
> java.sql.SQLException: Closed Resultset: next
> at
> oracle.jdbc.driver.InsensitiveScrollableResultSet.ensureOpen(InsensitiveScrollableResultSet.java:109)
> ~[ojdbc8.jar:12.2.0.1.0]
> at
> oracle.jdbc.driver.InsensitiveScrollableResultSet.next(InsensitiveScrollableResultSet.java:398)
> ~[ojdbc8.jar:12.2.0.1.0]
> at
> weblogic.jdbc.wrapper.ResultSet_oracle_jdbc_driver_ForwardOnlyResultSet.next(Unknown
> Source) ~[CodeGenerator.class:12.2.1.3]
> at
> org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader.readLastModified(DataSourceResourceLoader.java:326)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader.getLastModified(DataSourceResourceLoader.java:240)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:446)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:346)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1677)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1656)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.app.VelocityEngine.getTemplate(VelocityEngine.java:314)
> ~[velocity-engine-core-2.3.jar:2.3]
> {noformat}
> Reference:
> https://stackoverflow.com/questions/2794167/is-resultset-thread-safe
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-965) Velocity 1.7 vs velocity 2.3: Getting thread synchronization issue
[
https://issues.apache.org/jira/browse/VELOCITY-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17725731#comment-17725731
]
Amrit edited comment on VELOCITY-965 at 5/24/23 10:12 AM:
--
Generally what is the process to fix such issues for the Velocity project?
Would someone be looking into this issue and can we expect a fix anytime?
was (Author: JIRAUSER299929):
Generally what is process to fix such issues for the Velocity project? Would
someone be looking into this issue and can we expect a fix anytime?
> Velocity 1.7 vs velocity 2.3: Getting thread synchronization issue
> --
>
> Key: VELOCITY-965
> URL: https://issues.apache.org/jira/browse/VELOCITY-965
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Amrit
>Priority: Major
>
> Recently we migrated from Velocity 1.7 to Velocity 2.3. We see the below
> error intermittently which is a possible thread synchronization issue with
> Velocity Engine. The resultset is getting closed while another thread is
> making use of it.
> {noformat}
> 2023-04-15 10:36:33.472 ERROR [org.apache.velocity.loader.ds]
> {344} - DataSourceResourceLoader: database problem while getting timestamp of
> 'xyz_abc':
> java.sql.SQLException: Closed Resultset: next
> at
> oracle.jdbc.driver.InsensitiveScrollableResultSet.ensureOpen(InsensitiveScrollableResultSet.java:109)
> ~[ojdbc8.jar:12.2.0.1.0]
> at
> oracle.jdbc.driver.InsensitiveScrollableResultSet.next(InsensitiveScrollableResultSet.java:398)
> ~[ojdbc8.jar:12.2.0.1.0]
> at
> weblogic.jdbc.wrapper.ResultSet_oracle_jdbc_driver_ForwardOnlyResultSet.next(Unknown
> Source) ~[CodeGenerator.class:12.2.1.3]
> at
> org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader.readLastModified(DataSourceResourceLoader.java:326)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader.getLastModified(DataSourceResourceLoader.java:240)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:446)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:346)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1677)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1656)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.app.VelocityEngine.getTemplate(VelocityEngine.java:314)
> ~[velocity-engine-core-2.3.jar:2.3]
> {noformat}
> Reference:
> https://stackoverflow.com/questions/2794167/is-resultset-thread-safe
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-965) Velocity 1.7 vs velocity 2.3: Getting thread synchronization issue
[
https://issues.apache.org/jira/browse/VELOCITY-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17725731#comment-17725731
]
Amrit commented on VELOCITY-965:
Generally what is process to fix such issues for the Velocity project? Would
someone be looking into this issue and can we expect a fix anytime?
> Velocity 1.7 vs velocity 2.3: Getting thread synchronization issue
> --
>
> Key: VELOCITY-965
> URL: https://issues.apache.org/jira/browse/VELOCITY-965
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Amrit
>Priority: Major
>
> Recently we migrated from Velocity 1.7 to Velocity 2.3. We see the below
> error intermittently which is a possible thread synchronization issue with
> Velocity Engine. The resultset is getting closed while another thread is
> making use of it.
> {noformat}
> 2023-04-15 10:36:33.472 ERROR [org.apache.velocity.loader.ds]
> {344} - DataSourceResourceLoader: database problem while getting timestamp of
> 'xyz_abc':
> java.sql.SQLException: Closed Resultset: next
> at
> oracle.jdbc.driver.InsensitiveScrollableResultSet.ensureOpen(InsensitiveScrollableResultSet.java:109)
> ~[ojdbc8.jar:12.2.0.1.0]
> at
> oracle.jdbc.driver.InsensitiveScrollableResultSet.next(InsensitiveScrollableResultSet.java:398)
> ~[ojdbc8.jar:12.2.0.1.0]
> at
> weblogic.jdbc.wrapper.ResultSet_oracle_jdbc_driver_ForwardOnlyResultSet.next(Unknown
> Source) ~[CodeGenerator.class:12.2.1.3]
> at
> org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader.readLastModified(DataSourceResourceLoader.java:326)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader.getLastModified(DataSourceResourceLoader.java:240)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:446)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:346)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1677)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1656)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.app.VelocityEngine.getTemplate(VelocityEngine.java:314)
> ~[velocity-engine-core-2.3.jar:2.3]
> {noformat}
> Reference:
> https://stackoverflow.com/questions/2794167/is-resultset-thread-safe
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-965) Velocity 1.7 vs velocity 2.3: Getting thread synchronization issue
[
https://issues.apache.org/jira/browse/VELOCITY-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 ge
[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
[jira] [Created] (VELOCITY-965) Velocity 1.7 vs velocity 2.3: Getting thread synchronization issue
Amrit created VELOCITY-965:
--
Summary: Velocity 1.7 vs velocity 2.3: Getting thread
synchronization issue
Key: VELOCITY-965
URL: https://issues.apache.org/jira/browse/VELOCITY-965
Project: Velocity
Issue Type: Bug
Components: Engine
Affects Versions: 2.3
Reporter: Amrit
Recently we migrated from Velocity 1.7 to Velocity 2.3. We see the below error
intermittently which is a possible thread synchronization issue with Velocity
Engine. The resultset is getting closed while another thread is making use of
it.
2023-04-15 10:36:33.472 ERROR [org.apache.velocity.loader.ds] \{344} -
DataSourceResourceLoader: database problem while getting timestamp of
'xyz_abc':
java.sql.SQLException: Closed Resultset: next
at
oracle.jdbc.driver.InsensitiveScrollableResultSet.ensureOpen(InsensitiveScrollableResultSet.java:109)
~[ojdbc8.jar:12.2.0.1.0]
at
oracle.jdbc.driver.InsensitiveScrollableResultSet.next(InsensitiveScrollableResultSet.java:398)
~[ojdbc8.jar:12.2.0.1.0]
at
weblogic.jdbc.wrapper.ResultSet_oracle_jdbc_driver_ForwardOnlyResultSet.next(Unknown
Source) ~[CodeGenerator.class:12.2.1.3]
at
org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader.readLastModified(DataSourceResourceLoader.java:326)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader.getLastModified(DataSourceResourceLoader.java:240)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:446)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:346)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1677)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1656)
~[velocity-engine-core-2.3.jar:2.3]
at
org.apache.velocity.app.VelocityEngine.getTemplate(VelocityEngine.java:314)
~[velocity-engine-core-2.3.jar:2.3]
Reference:
https://stackoverflow.com/questions/2794167/is-resultset-thread-safe
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-952) Velocity is calling the "wrong" method
[
https://issues.apache.org/jira/browse/VELOCITY-952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17711273#comment-17711273
]
Thomas Mortagne commented on VELOCITY-952:
--
bq. an uberspector on XWiki side
Implemented on
https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodOverrideUberspector.java
> Velocity is calling the "wrong" method
> --
>
> Key: VELOCITY-952
> URL: https://issues.apache.org/jira/browse/VELOCITY-952
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Thomas Mortagne
>Priority: Major
>
> OK, the title is maybe a bit harsh, but it catches the eyes :)
> At XWiki we recently started testing on Java 17 to see if there is any
> problem which leaded us to add things like {{--add-opens
> java.base/java.util=ALL-UNNAMED}} but Velocity happen to be the source of
> another problem related to the new module world.
> When doing something like {{$datetool.timeZone.getOffset(0)}} ($datetool
> being the org.apache.velocity.tools.generic.DateTool) we get the following
> error:
> {noformat}
> ...
> Caused by: java.lang.IllegalAccessException: class
> org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl cannot
> access class sun.util.calendar.ZoneInfo (in module java.base) because module
> java.base does not export sun.util.calendar to unnamed module @7ca16adc
> at
> java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:392)
> at
> java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674)
> at java.base/java.lang.reflect.Method.invoke(Method.java:560)
> at
> org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:571)
> at
> org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:554)
> at
> org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:221)
> ... 199 more
> {noformat}
> The reason is that while the developer intent/expectation was to call
> "java.util.TimeZone#getOffset(0)" what Velocity really called from JVM point
> of view is "sun.util.calendar.ZoneInfo.getOffset(0)" directly.
> That's because Velocity is doing (I assume, since I did not check the exact
> code) the equivalent of:
> {noformat}
> java.util.TimeZone.getDefault().getClass().getMethod("getOffset",
> long.class).invoke(TimeZone.getDefault(), 0);
> {noformat}
> which is itself the equivalent of:
> {noformat}
> sun.util.calendar.ZoneInfo.class.getMethod("getOffset",
> long.class).invoke(TimeZone.getDefault(), 0);
> {noformat}
> I guess the only way to fix this would be to track down the lowest overridden
> Method (I agree, it might not always be easy to choose between two interfaces
> declaring a method with the same signature, but choosing the first one we
> find from the same hierarchy level is still better than nothing) and call
> that one instead. With the use case used as example in this issue, that would
> mean ending up doing the equivalent of:
> {noformat}
> java.util.TimeZone.class.getMethod("getOffset",
> long.class).invoke(TimeZone.getDefault(), 0);
> {noformat}
> which, from JVM point of view, is covered by the {{--add-opens
> java.base/java.util=ALL-UNNAMED}}.
> It would be a big change, but at least can't think of any retro-compatibility
> problem it might cause.
> One might be tempted to answer "just add {{--add-opens
> java.base/sun.util.calendar=ALL-UNNAMED}}" but it does not seem fair as this
> is not what the API that the script uses was exposing at all, you might need
> to document a different one for each JVM implementation (even if it's
> probably unlikely for this specific example) but more importantly you will
> potentially need quite a lot of those and will only discover it at runtime
> since it's not so easy to guess from an API in which you only know the public
> JVM classes since that's what you manipulate.
> I would be happy to work on this, but I wanted first ask what others think
> about this problem in general and the possible solutions I may have missed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-952) Velocity is calling the "wrong" method
[
https://issues.apache.org/jira/browse/VELOCITY-952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17710993#comment-17710993
]
Thomas Mortagne commented on VELOCITY-952:
--
{quote}
bq. respecting the method return type
Carrying this information around with the object sounds like a complex thing to
change (but maybe not, I don't know the Velocity AST very well), but I agree
it's probably the most accurate.
{quote}
So I finally did some digging on what it would take to implement this idea, and
it's indeed not trivial. From what I understood, the problem is that here is no
way to associate metadata to a value in the context right now, so all the APIs
which manipulate the value of a variable don't have any way to pass/return more
info about this value (thinking especially about associating a Type with the
value in the Context and how to return a Type along with the value returned by
ASTMethod#execute.
I started by refactoring a bit {{org.apache.velocity.context.Context}} to
support associating metadata to an entry without breaking existing API, but
then the number of things to change in pretty critical places to take this into
account is a bit overwhelming for me and a huge challenge in terms of retro
compatibly without really knowing if that's really the direction that you guys
want to take.
Problem is that this bug makes pretty much impossible to say that XWiki
supports Java 17 because of the many unforeseen IllegalAccessException failures
you can end up with depending on which apparently standard Java API you are
manipulating in a script. So for now my plan is to workaround this with an
uberspector on XWiki side doing what I initially proposed: try to find the
lowest overwritten Method (which, I agree, is not the best and not something I
would recommend on standard Velocity side compared to the "carry the return
type around with the value" idea).
> Velocity is calling the "wrong" method
> --
>
> Key: VELOCITY-952
> URL: https://issues.apache.org/jira/browse/VELOCITY-952
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Thomas Mortagne
>Priority: Major
>
> OK, the title is maybe a bit harsh, but it catches the eyes :)
> At XWiki we recently started testing on Java 17 to see if there is any
> problem which leaded us to add things like {{--add-opens
> java.base/java.util=ALL-UNNAMED}} but Velocity happen to be the source of
> another problem related to the new module world.
> When doing something like {{$datetool.timeZone.getOffset(0)}} ($datetool
> being the org.apache.velocity.tools.generic.DateTool) we get the following
> error:
> {noformat}
> ...
> Caused by: java.lang.IllegalAccessException: class
> org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl cannot
> access class sun.util.calendar.ZoneInfo (in module java.base) because module
> java.base does not export sun.util.calendar to unnamed module @7ca16adc
> at
> java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:392)
> at
> java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674)
> at java.base/java.lang.reflect.Method.invoke(Method.java:560)
> at
> org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:571)
> at
> org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:554)
> at
> org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:221)
> ... 199 more
> {noformat}
> The reason is that while the developer intent/expectation was to call
> "java.util.TimeZone#getOffset(0)" what Velocity really called from JVM point
> of view is "sun.util.calendar.ZoneInfo.getOffset(0)" directly.
> That's because Velocity is doing (I assume, since I did not check the exact
> code) the equivalent of:
> {noformat}
> java.util.TimeZone.getDefault().getClass().getMethod("getOffset",
> long.class).invoke(TimeZone.getDefault(), 0);
> {noformat}
> which is itself the equivalent of:
> {noformat}
> sun.util.calendar.ZoneInfo.class.getMethod("getOffset",
> long.class).invoke(TimeZone.getDefault(), 0);
> {noformat}
> I guess the only way to fix this would be to track down the lowest overridden
> Method (I agree, it might not always be easy to choose between two interfaces
> declaring a method with the same signature, but choosing the first one we
> find from the same hierarchy level is still better than nothing) and call
> that one instead. With the use case used as example in
[jira] [Assigned] (VELTOOLS-201) Document $esc.unicode() in Javadoc and page listing
[
https://issues.apache.org/jira/browse/VELTOOLS-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned VELTOOLS-201:
---
Assignee: (was: Michael Osipov)
> Document $esc.unicode() in Javadoc and page listing
> ---
>
> Key: VELTOOLS-201
> URL: https://issues.apache.org/jira/browse/VELTOOLS-201
> Project: Velocity Tools
> Issue Type: Task
> Components: GenericTools
>Affects Versions: 3.1
>Reporter: Michael Osipov
>Priority: Major
>
> No example for {{$esc.unicode()}} is provided here:
> https://velocity.apache.org/tools/3.1/apidocs/org/apache/velocity/tools/generic/EscapeTool.html
> nor is it mentioned here:
> https://velocity.apache.org/tools/3.1/tools-summary.html#EscapeTool
> Took me some time to find out have I can type in {{\uXXXX}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
