[jira] [Closed] (VELTOOLS-206) Upgrade to Velocity Engine 2.4
[ https://issues.apache.org/jira/browse/VELTOOLS-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed VELTOOLS-206. --- Resolution: Fixed Fixed with [69fbb0ed4c0ecd936b2a9b839820717893f3dd72|https://gitbox.apache.org/repos/asf?p=velocity-tools.git;a=commit;h=69fbb0ed4c0ecd936b2a9b839820717893f3dd72]. > Upgrade to Velocity Engine 2.4 > -- > > 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-984) Velocity calls method of abstract superclass leading to an IllegalAccessException
[ https://issues.apache.org/jira/browse/VELOCITY-984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887138#comment-17887138 ] Thomas Mortagne commented on VELOCITY-984: -- bq. Do you think you could provide a patch? Sure, but I won't have time to work on that before Tuesday, unfortunately. > Velocity calls method of abstract superclass leading to an > IllegalAccessException > - > > Key: VELOCITY-984 > URL: https://issues.apache.org/jira/browse/VELOCITY-984 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.4 >Reporter: Christoph Lenggenhager >Priority: Major > Attachments: Velocity952TestCase.java > > > With the changes introduced in VELOCITY-952, our templates fail with an > IllegalAccessException. > The exception is caused by a template that has a variable of type > StringBuilder and calls append on it. The introduced changes choose the > implementation of the method of AbstractStringBuilder to be executed, which > leads to the mentioned IllegalAccessExceptions. > I've attached an extended version of Velocity952TestCase.java that reproduces > the problem with an additional test. > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-984) Velocity calls method of abstract superclass leading to an IllegalAccessException
[ https://issues.apache.org/jira/browse/VELOCITY-984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887087#comment-17887087 ] Claude Brisson commented on VELOCITY-984: - Yes [~tmortagne] you are certainly right, it will have less side effects. Do you think you could provide a patch? > Velocity calls method of abstract superclass leading to an > IllegalAccessException > - > > Key: VELOCITY-984 > URL: https://issues.apache.org/jira/browse/VELOCITY-984 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.4 >Reporter: Christoph Lenggenhager >Priority: Major > Attachments: Velocity952TestCase.java > > > With the changes introduced in VELOCITY-952, our templates fail with an > IllegalAccessException. > The exception is caused by a template that has a variable of type > StringBuilder and calls append on it. The introduced changes choose the > implementation of the method of AbstractStringBuilder to be executed, which > leads to the mentioned IllegalAccessExceptions. > I've attached an extended version of Velocity952TestCase.java that reproduces > the problem with an additional test. > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-984) Velocity calls method of abstract superclass leading to an IllegalAccessException
[ https://issues.apache.org/jira/browse/VELOCITY-984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17886924#comment-17886924 ] Thomas Mortagne edited comment on VELOCITY-984 at 10/4/24 2:24 PM: --- Indeed, I can reproduce the error you have with the test you provided when building Velocity (with Java 21, but I'm not sure it matter much actually). I think this is simply because AbstractStringBuilder is package protected (which is not the case of StringBuilder). [~cbrisson] I feel like the logic of getTopMostMethodDeclaration should be modified a bit to stop at the first accessible method (so more of a getAccessibleMethodDeclaration), like I did in https://github.com/xwiki/xwiki-commons/blob/xwiki-commons-15.10/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodOverrideUberspector.java, instead of always going all the way to the top. It should cover problems like this (and it means stopping earlier in most cases, which is probably better for performances) was (Author: tmortagne): Indeed, I can reproduce the error you have with the test you provided when building Velocity with Java 21. I think this is simply because AbstractStringBuilder is package protected (which is not the case of StringBuilder). [~cbrisson] I feel like the logic of getTopMostMethodDeclaration should be modified a bit to stop at the first accessible method (so more of a getAccessibleMethodDeclaration), like I did in https://github.com/xwiki/xwiki-commons/blob/xwiki-commons-15.10/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodOverrideUberspector.java, instead of always going all the way to the top. It should cover problems like this (and it means stopping earlier in most cases, which is probably better for performances) > Velocity calls method of abstract superclass leading to an > IllegalAccessException > - > > Key: VELOCITY-984 > URL: https://issues.apache.org/jira/browse/VELOCITY-984 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.4 >Reporter: Christoph Lenggenhager >Priority: Major > Attachments: Velocity952TestCase.java > > > With the changes introduced in VELOCITY-952, our templates fail with an > IllegalAccessException. > The exception is caused by a template that has a variable of type > StringBuilder and calls append on it. The introduced changes choose the > implementation of the method of AbstractStringBuilder to be executed, which > leads to the mentioned IllegalAccessExceptions. > I've attached an extended version of Velocity952TestCase.java that reproduces > the problem with an additional test. > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-984) Velocity calls method of abstract superclass leading to an IllegalAccessException
[ https://issues.apache.org/jira/browse/VELOCITY-984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17886924#comment-17886924 ] Thomas Mortagne edited comment on VELOCITY-984 at 10/4/24 1:52 PM: --- Indeed, I can reproduce the error you have with the test you provided when building Velocity with Java 21. I think this is simply because AbstractStringBuilder is package protected (which is not the case of StringBuilder). [~cbrisson] I feel like the logic of getTopMostMethodDeclaration should be modified a bit to stop at the first accessible method (so more of a getAccessibleMethodDeclaration), like I did in https://github.com/xwiki/xwiki-commons/blob/xwiki-commons-15.10/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodOverrideUberspector.java, instead of always going all the way to the top. It should cover problems like this (and it means stopping earlier in most cases, which is probably better for performances) was (Author: tmortagne): Indeed, I can reproduce the error you have with the test you provided when building Velocity with Java 21. I think this is simply because AbstractStringBuilder is package protected (which is not the case of StringBuilder). [~cbrisson] I feel like the logic of getTopMostMethodDeclaration should be modified a bit to stop at the first accessible method (so more of a getAccessibleMethodDeclaration) instead of always going all the way to the top, like I did in https://github.com/xwiki/xwiki-commons/blob/xwiki-commons-15.10/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodOverrideUberspector.java. It should cover problems like this (and it means stopping earlier in most cases, which is probably better for performances) > Velocity calls method of abstract superclass leading to an > IllegalAccessException > - > > Key: VELOCITY-984 > URL: https://issues.apache.org/jira/browse/VELOCITY-984 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.4 >Reporter: Christoph Lenggenhager >Priority: Major > Attachments: Velocity952TestCase.java > > > With the changes introduced in VELOCITY-952, our templates fail with an > IllegalAccessException. > The exception is caused by a template that has a variable of type > StringBuilder and calls append on it. The introduced changes choose the > implementation of the method of AbstractStringBuilder to be executed, which > leads to the mentioned IllegalAccessExceptions. > I've attached an extended version of Velocity952TestCase.java that reproduces > the problem with an additional test. > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-984) Velocity calls method of abstract superclass leading to an IllegalAccessException
[ https://issues.apache.org/jira/browse/VELOCITY-984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17886924#comment-17886924 ] Thomas Mortagne commented on VELOCITY-984: -- Indeed, I can reproduce the error you have with the test you provided when building Velocity with Java 21. I think this is simply because AbstractStringBuilder is package protected (which is not the case of StringBuilder). [~cbrisson] I feel like the logic of getTopMostMethodDeclaration should be modified a bit to stop at the first accessible method (so more of a getAccessibleMethodDeclaration) instead of always going all the way to the top, like I did in https://github.com/xwiki/xwiki-commons/blob/xwiki-commons-15.10/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodOverrideUberspector.java. It should cover problems like this (and it means stopping earlier in most cases, which is probably better for performances) > Velocity calls method of abstract superclass leading to an > IllegalAccessException > - > > Key: VELOCITY-984 > URL: https://issues.apache.org/jira/browse/VELOCITY-984 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.4 >Reporter: Christoph Lenggenhager >Priority: Major > Attachments: Velocity952TestCase.java > > > With the changes introduced in VELOCITY-952, our templates fail with an > IllegalAccessException. > The exception is caused by a template that has a variable of type > StringBuilder and calls append on it. The introduced changes choose the > implementation of the method of AbstractStringBuilder to be executed, which > leads to the mentioned IllegalAccessExceptions. > I've attached an extended version of Velocity952TestCase.java that reproduces > the problem with an additional test. > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Created] (VELOCITY-984) Velocity calls method of abstract superclass leading to an IllegalAccessException
Christoph Lenggenhager created VELOCITY-984: --- Summary: Velocity calls method of abstract superclass leading to an IllegalAccessException Key: VELOCITY-984 URL: https://issues.apache.org/jira/browse/VELOCITY-984 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 2.4 Reporter: Christoph Lenggenhager Attachments: Velocity952TestCase.java With the changes introduced in VELOCITY-952, our templates fail with an IllegalAccessException. The exception is caused by a template that has a variable of type StringBuilder and calls append on it. The introduced changes choose the implementation of the method of AbstractStringBuilder to be executed, which leads to the mentioned IllegalAccessExceptions. I've attached an extended version of Velocity952TestCase.java that reproduces the problem with an additional test. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Closed] (VELOCITY-983) Velocity calls the wrong static "overwritten" method
[ https://issues.apache.org/jira/browse/VELOCITY-983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson closed VELOCITY-983. --- Fix Version/s: 2.4.1 Assignee: Claude Brisson Resolution: Fixed PR merged. Thanks, [~tmortagne] . > Velocity calls the wrong static "overwritten" method > > > Key: VELOCITY-983 > URL: https://issues.apache.org/jira/browse/VELOCITY-983 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.4 >Reporter: Thomas Mortagne >Assignee: Claude Brisson >Priority: Blocker > Fix For: 2.4.1 > > > Unfortunately, in my proposal in VELOCITY-952 I totally missed one use case > which is now broken: a static method being "overwritten". Since Velocity 2.4, > the deepest static method will be called instead of the one in the object we > actually manipulate and unfortunately since static overrides are not real > overrides it means it's going to call the wrong one. > The reason [the uberspector I was using with Velocity > 2.3|https://github.com/xwiki/xwiki-commons/blob/a21846242821db564378bb68b1060fa42c632d16/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodOverrideUberspector.java#L116] > was not impacted is because I had an optimization to stop searching when > hitting the first accessible method (since my focus was > IllegalAccessException problems). -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Reopened] (VELOCITY-944) Macros in string literals are not resolved when local_scope is enabled
[
https://issues.apache.org/jira/browse/VELOCITY-944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jakub Isakow reopened VELOCITY-944:
---
> Macros in string literals are not resolved when local_scope is enabled
> --
>
> Key: VELOCITY-944
> URL: https://issues.apache.org/jira/browse/VELOCITY-944
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.0, 2.1, 2.2, 2.3
>Reporter: Jakub Isakow
>Assignee: Claude Brisson
>Priority: Critical
> Attachments: VelocityTest.java, pom.xml
>
>
> When local scope is enabled with
> {noformat}
> velocimacro.inline.local_scope=true
> {noformat}
> a template that is using a macro in string literal is not working correctly.
> Example template:
> {code}
> #macro( m $v )
> $v
> #end
> #set($v = "#m('bar')")
> $v
> #m( 'foo' )
> {code}
> Actual result:
> {code}
> #m('bar')
> foo
> {code}
> Expected result:
> {code}
> bar
> foo
> {code}
> The example template is working correctly for velocity 1.7.
> After debugging a bit I think the problem might be caused by creating a new
> Template instance in
> [org.apache.velocity.runtime.parser.node.ASTStringLiteral#init|https://github.com/apache/velocity-engine/blob/2.3/velocity-engine-core/src/main/java/org/apache/velocity/runtime/parser/node/ASTStringLiteral.java#L145-L149].
> Because of that, when macro is being resolved, there is no macro instance
> available in local scope (template instance) and it is rendered as string.
> Locally I was able to make it work by using {{this.template}} when
> {{context.getCurrentResource()}} returns {{null}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-944) Macros in string literals are not resolved when local_scope is enabled
[
https://issues.apache.org/jira/browse/VELOCITY-944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17886653#comment-17886653
]
Jakub Isakow commented on VELOCITY-944:
---
I've attached pom.xml and a test file. The
{code}
mvn clean test
{code}
ends with
{noformat}
---
T E S T S
---
Running VelocityTest
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further
details.
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.282 sec <<<
FAILURE!
name(VelocityTest) Time elapsed: 0.216 sec <<< FAILURE!
org.junit.ComparisonFailure:
Expecting actual:
"foo
some text #m( 'bar' )"
to be equal to:
"foo
some text bar"
...
{noformat}
> Macros in string literals are not resolved when local_scope is enabled
> --
>
> Key: VELOCITY-944
> URL: https://issues.apache.org/jira/browse/VELOCITY-944
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.0, 2.1, 2.2, 2.3
>Reporter: Jakub Isakow
>Assignee: Claude Brisson
>Priority: Critical
> Attachments: VelocityTest.java, pom.xml
>
>
> When local scope is enabled with
> {noformat}
> velocimacro.inline.local_scope=true
> {noformat}
> a template that is using a macro in string literal is not working correctly.
> Example template:
> {code}
> #macro( m $v )
> $v
> #end
> #set($v = "#m('bar')")
> $v
> #m( 'foo' )
> {code}
> Actual result:
> {code}
> #m('bar')
> foo
> {code}
> Expected result:
> {code}
> bar
> foo
> {code}
> The example template is working correctly for velocity 1.7.
> After debugging a bit I think the problem might be caused by creating a new
> Template instance in
> [org.apache.velocity.runtime.parser.node.ASTStringLiteral#init|https://github.com/apache/velocity-engine/blob/2.3/velocity-engine-core/src/main/java/org/apache/velocity/runtime/parser/node/ASTStringLiteral.java#L145-L149].
> Because of that, when macro is being resolved, there is no macro instance
> available in local scope (template instance) and it is rendered as string.
> Locally I was able to make it work by using {{this.template}} when
> {{context.getCurrentResource()}} returns {{null}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-944) Macros in string literals are not resolved when local_scope is enabled
[
https://issues.apache.org/jira/browse/VELOCITY-944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jakub Isakow updated VELOCITY-944:
--
Attachment: VelocityTest.java
> Macros in string literals are not resolved when local_scope is enabled
> --
>
> Key: VELOCITY-944
> URL: https://issues.apache.org/jira/browse/VELOCITY-944
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.0, 2.1, 2.2, 2.3
>Reporter: Jakub Isakow
>Assignee: Claude Brisson
>Priority: Critical
> Attachments: VelocityTest.java, pom.xml
>
>
> When local scope is enabled with
> {noformat}
> velocimacro.inline.local_scope=true
> {noformat}
> a template that is using a macro in string literal is not working correctly.
> Example template:
> {code}
> #macro( m $v )
> $v
> #end
> #set($v = "#m('bar')")
> $v
> #m( 'foo' )
> {code}
> Actual result:
> {code}
> #m('bar')
> foo
> {code}
> Expected result:
> {code}
> bar
> foo
> {code}
> The example template is working correctly for velocity 1.7.
> After debugging a bit I think the problem might be caused by creating a new
> Template instance in
> [org.apache.velocity.runtime.parser.node.ASTStringLiteral#init|https://github.com/apache/velocity-engine/blob/2.3/velocity-engine-core/src/main/java/org/apache/velocity/runtime/parser/node/ASTStringLiteral.java#L145-L149].
> Because of that, when macro is being resolved, there is no macro instance
> available in local scope (template instance) and it is rendered as string.
> Locally I was able to make it work by using {{this.template}} when
> {{context.getCurrentResource()}} returns {{null}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-944) Macros in string literals are not resolved when local_scope is enabled
[
https://issues.apache.org/jira/browse/VELOCITY-944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jakub Isakow updated VELOCITY-944:
--
Attachment: pom.xml
> Macros in string literals are not resolved when local_scope is enabled
> --
>
> Key: VELOCITY-944
> URL: https://issues.apache.org/jira/browse/VELOCITY-944
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.0, 2.1, 2.2, 2.3
>Reporter: Jakub Isakow
>Assignee: Claude Brisson
>Priority: Critical
> Attachments: VelocityTest.java, pom.xml
>
>
> When local scope is enabled with
> {noformat}
> velocimacro.inline.local_scope=true
> {noformat}
> a template that is using a macro in string literal is not working correctly.
> Example template:
> {code}
> #macro( m $v )
> $v
> #end
> #set($v = "#m('bar')")
> $v
> #m( 'foo' )
> {code}
> Actual result:
> {code}
> #m('bar')
> foo
> {code}
> Expected result:
> {code}
> bar
> foo
> {code}
> The example template is working correctly for velocity 1.7.
> After debugging a bit I think the problem might be caused by creating a new
> Template instance in
> [org.apache.velocity.runtime.parser.node.ASTStringLiteral#init|https://github.com/apache/velocity-engine/blob/2.3/velocity-engine-core/src/main/java/org/apache/velocity/runtime/parser/node/ASTStringLiteral.java#L145-L149].
> Because of that, when macro is being resolved, there is no macro instance
> available in local scope (template instance) and it is rendered as string.
> Locally I was able to make it work by using {{this.template}} when
> {{context.getCurrentResource()}} returns {{null}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-983) Velocity calls the wrong static "overwritten" method
[ https://issues.apache.org/jira/browse/VELOCITY-983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17885831#comment-17885831 ] Thomas Mortagne commented on VELOCITY-983: -- Created https://github.com/apache/velocity-engine/pull/53 > Velocity calls the wrong static "overwritten" method > > > Key: VELOCITY-983 > URL: https://issues.apache.org/jira/browse/VELOCITY-983 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.4 >Reporter: Thomas Mortagne >Priority: Blocker > > Unfortunately, in my proposal in VELOCITY-952 I totally missed one use case > which is now broken: a static method being "overwritten". Since Velocity 2.4, > the deepest static method will be called instead of the one in the object we > actually manipulate and unfortunately since static overrides are not real > overrides it means it's going to call the wrong one. > The reason [the uberspector I was using with Velocity > 2.3|https://github.com/xwiki/xwiki-commons/blob/a21846242821db564378bb68b1060fa42c632d16/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodOverrideUberspector.java#L116] > was not impacted is because I had an optimization to stop searching when > hitting the first accessible method (since my focus was > IllegalAccessException problems). -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-983) Velocity calls the wrong static "overwritten" method
[ https://issues.apache.org/jira/browse/VELOCITY-983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mortagne updated VELOCITY-983: - Summary: Velocity calls the wrong static "overwritten" method (was: Velocity calls the wrong static overwritten method) > Velocity calls the wrong static "overwritten" method > > > Key: VELOCITY-983 > URL: https://issues.apache.org/jira/browse/VELOCITY-983 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.4 >Reporter: Thomas Mortagne >Priority: Blocker > > Unfortunately, in my proposal in VELOCITY-952 I totally missed one use case > which is now broken: a static method being "overwritten". Since Velocity 2.4, > the deepest static method will be called instead of the one in the object we > actually manipulate and unfortunately since static overrides are not real > overrides it means it's going to call the wrong one. > The reason [the uberspector I was using with Velocity > 2.3|https://github.com/xwiki/xwiki-commons/blob/a21846242821db564378bb68b1060fa42c632d16/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodOverrideUberspector.java#L116] > was not impacted is because I had an optimization to stop searching when > hitting the first accessible method (since my focus was > IllegalAccessException problems). -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-983) Velocity calls the wrong static overwritten method
[ https://issues.apache.org/jira/browse/VELOCITY-983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mortagne updated VELOCITY-983: - Summary: Velocity calls the wrong static overwritten method (was: Velocity calles the wrong static overwritten method) > Velocity calls the wrong static overwritten method > -- > > Key: VELOCITY-983 > URL: https://issues.apache.org/jira/browse/VELOCITY-983 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.4 >Reporter: Thomas Mortagne >Priority: Blocker > > Unfortunately, in my proposal in VELOCITY-952 I totally missed one use case > which is now broken: a static method being "overwritten". Since Velocity 2.4, > the deepest static method will be called instead of the one in the object we > actually manipulate and unfortunately since static overrides are not real > overrides it means it's going to call the wrong one. > The reason [the uberspector I was using with Velocity > 2.3|https://github.com/xwiki/xwiki-commons/blob/a21846242821db564378bb68b1060fa42c632d16/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodOverrideUberspector.java#L116] > was not impacted is because I had an optimization to stop searching when > hitting the first accessible method (since my focus was > IllegalAccessException problems). -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Created] (VELOCITY-983) Velocity calles the wrong static overwritten method
Thomas Mortagne created VELOCITY-983: Summary: Velocity calles the wrong static overwritten method Key: VELOCITY-983 URL: https://issues.apache.org/jira/browse/VELOCITY-983 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 2.4 Reporter: Thomas Mortagne Unfortunately, in my proposal in VELOCITY-952 I totally missed one use case which is now broken: a static method being "overwritten". Since Velocity 2.4, the deepest static method will be called instead of the one in the object we actually manipulate and unfortunately since static overrides are not real overrides it means it's going to call the wrong one. The reason [the uberspector I was using with Velocity 2.3|https://github.com/xwiki/xwiki-commons/blob/a21846242821db564378bb68b1060fa42c632d16/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodOverrideUberspector.java#L116] was not impacted is because I had an optimization to stop searching when hitting the first accessible method (since my focus was IllegalAccessException problems). -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-952) Velocity is calling the "wrong" method
[
https://issues.apache.org/jira/browse/VELOCITY-952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17711273#comment-17711273
]
Thomas Mortagne edited comment on VELOCITY-952 at 9/30/24 8:00 AM:
---
bq. an uberspector on XWiki side
Implemented on
https://github.com/xwiki/xwiki-commons/blob/xwiki-commons-15.10/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodOverrideUberspector.java
was (Author: tmortagne):
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
>Assignee: Claude Brisson
>Priority: Major
> Fix For: 2.4
>
>
> OK, the title is maybe a bit harsh, but it catches the eyes :)
> At XWiki we recently started testing on Java 17 to see if there is any
> problem which leaded us to add things like {{--add-opens
> java.base/java.util=ALL-UNNAMED}} but Velocity happen to be the source of
> another problem related to the new module world.
> When doing something like {{$datetool.timeZone.getOffset(0)}} ($datetool
> being the org.apache.velocity.tools.generic.DateTool) we get the following
> error:
> {noformat}
> ...
> Caused by: java.lang.IllegalAccessException: class
> org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl cannot
> access class sun.util.calendar.ZoneInfo (in module java.base) because module
> java.base does not export sun.util.calendar to unnamed module @7ca16adc
> at
> java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:392)
> at
> java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674)
> at java.base/java.lang.refledact.Method.invoke(Method.java:560)
> at
> org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:571)
> at
> org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:554)
> at
> org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:221)
> ... 199 more
> {noformat}
> The reason is that while the developer intent/expectation was to call
> "java.util.TimeZone#getOffset(0)" what Velocity really called from JVM point
> of view is "sun.util.calendar.ZoneInfo.getOffset(0)" directly.
> That's because Velocity is doing (I assume, since I did not check the exact
> code) the equivalent of:
> {noformat}
> java.util.TimeZone.getDefault().getClass().getMethod("getOffset",
> long.class).invoke(TimeZone.getDefault(), 0);
> {noformat}
> which is itself the equivalent of:
> {noformat}
> sun.util.calendar.ZoneInfo.class.getMethod("getOffset",
> long.class).invoke(TimeZone.getDefault(), 0);
> {noformat}
> I guess the only way to fix this would be to track down the lowest overridden
> Method (I agree, it might not always be easy to choose between two interfaces
> declaring a method with the same signature, but choosing the first one we
> find from the same hierarchy level is still better than nothing) and call
> that one instead. With the use case used as example in this issue, that would
> mean ending up doing the equivalent of:
> {noformat}
> java.util.TimeZone.class.getMethod("getOffset",
> long.class).invoke(TimeZone.getDefault(), 0);
> {noformat}
> which, from JVM point of view, is covered by the {{--add-opens
> java.base/java.util=ALL-UNNAMED}}.
> It would be a big change, but at least can't think of any retro-compatibility
> problem it might cause.
> One might be tempted to answer "just add {{--add-opens
> java.base/sun.util.calendar=ALL-UNNAMED}}" but it does not seem fair as this
> is not what the API that the script uses was exposing at all, you might need
> to document a different one for each JVM implementation (even if it's
> probably unlikely for this specific example) but more importantly you will
> potentially need quite a lot of those and will only discover it at runtime
> since it's not so easy to guess from an API in which you only know the public
> JVM classes since that's what you manipulate.
> I would be happy to work on this, but I want
[jira] [Assigned] (VELTOOLS-206) Upgrade to Velocity Engine 2.4
[ https://issues.apache.org/jira/browse/VELTOOLS-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reassigned VELTOOLS-206: --- Assignee: Michael Osipov > Upgrade to Velocity Engine 2.4 > -- > > 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
[ 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 (was: Upgrade to Velocity Engine 2.4.2) > Upgrade to Velocity Engine 2.4 > -- > > 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] [Updated] (VELOCITY-981) Upgrade to Parent 7
[ https://issues.apache.org/jira/browse/VELOCITY-981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson updated VELOCITY-981: Fix Version/s: (was: 2.4.2) > Upgrade to Parent 7 > --- > > Key: VELOCITY-981 > URL: https://issues.apache.org/jira/browse/VELOCITY-981 > Project: Velocity > Issue Type: Task > Components: Build >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 2.4 > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-977) Upgrade Java Compiler Compiler to Version 7.0.13
[ https://issues.apache.org/jira/browse/VELOCITY-977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson updated VELOCITY-977: Fix Version/s: (was: 2.4.2) > Upgrade Java Compiler Compiler to Version 7.0.13 > > > Key: VELOCITY-977 > URL: https://issues.apache.org/jira/browse/VELOCITY-977 > Project: Velocity > Issue Type: Improvement >Reporter: Sylwester Lachiewicz >Assignee: Michael Osipov >Priority: Minor > Fix For: 2.4 > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-951) DataSourceResourceLoader: property datasource_url wrong
[
https://issues.apache.org/jira/browse/VELOCITY-951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson updated VELOCITY-951:
Fix Version/s: (was: 2.4.1)
(was: 2.4.2)
> DataSourceResourceLoader: property datasource_url wrong
> ---
>
> Key: VELOCITY-951
> URL: https://issues.apache.org/jira/browse/VELOCITY-951
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Andreas Sachs
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 2.4
>
>
> According to the javadoc it's
> resource.loader.ds.{*}resource.{*}datasource_url =
> java:comp/env/jdbc/Velocity
> resource.loader.ds.resource.table = tb_velocity_template
>
> But in the implementation "resource" is missing (only for datasource_url):
> dataSourceName = StringUtils.trim(configuration.getString("datasource_url"));
> tableName = StringUtils.trim(configuration.getString("resource.table"));
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-972) Remove Commons IO
[ https://issues.apache.org/jira/browse/VELOCITY-972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson updated VELOCITY-972: Fix Version/s: (was: 2.4.1) (was: 2.4.2) > Remove Commons IO > - > > Key: VELOCITY-972 > URL: https://issues.apache.org/jira/browse/VELOCITY-972 > Project: Velocity > Issue Type: Task > Components: Build, Engine >Affects Versions: 2.3 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 2.4 > > > There are only a few spots where Commons IO is used. These can be removed for > the two reasons: > * Replace with NIO2 methods > * Take input as-is since behavior has never been part of the contract > (Javadoc) -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-973) Upgrade dependencies
[ https://issues.apache.org/jira/browse/VELOCITY-973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson updated VELOCITY-973: Fix Version/s: (was: 2.4.1) (was: 2.4.2) > Upgrade dependencies > > > Key: VELOCITY-973 > URL: https://issues.apache.org/jira/browse/VELOCITY-973 > Project: Velocity > Issue Type: Task >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 2.4 > > > * Upgrade to SLF4J 1.7.36 > * Upgrade to Commons Lang 3.14.0 > * Upgrade to Spring Framework 5.3.31 > * Upgrade to HSQLDB 2.7.2 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-974) Use non-deprecated config property for resource loaders in VelocityEngineFactory
[ https://issues.apache.org/jira/browse/VELOCITY-974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson updated VELOCITY-974: Fix Version/s: (was: 2.4.1) (was: 2.4.2) > Use non-deprecated config property for resource loaders in > VelocityEngineFactory > > > Key: VELOCITY-974 > URL: https://issues.apache.org/jira/browse/VELOCITY-974 > Project: Velocity > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 2.4 > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-958) Template should be cloneable
[ https://issues.apache.org/jira/browse/VELOCITY-958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson updated VELOCITY-958: Fix Version/s: (was: 2.4.1) (was: 2.4.2) > Template should be cloneable > > > Key: VELOCITY-958 > URL: https://issues.apache.org/jira/browse/VELOCITY-958 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.3 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Minor > Fix For: 2.4 > > > Templates should be cloneable, the clone() method returning a template with a > deep clone of the AST tree. > It allows for dynamic transformations of the AST tree which don't affect the > original template. > One use case is the translation of ASTText nodes. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-940) bodyContent in nested macros called without @ should be unset
[
https://issues.apache.org/jira/browse/VELOCITY-940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson updated VELOCITY-940:
Fix Version/s: (was: 2.4.1)
(was: 2.4.2)
> bodyContent in nested macros called without @ should be unset
> -
>
> Key: VELOCITY-940
> URL: https://issues.apache.org/jira/browse/VELOCITY-940
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 1.7.x, 2.3
>Reporter: Willow Nice
>Assignee: Claude Brisson
>Priority: Minor
> Fix For: 2.4
>
>
> Hi! First ever maybe bug report (pls be gentle).
>
> {{#macro(test $label)Something $!label $!bodyContent#\{end}}}
> {{#@test('First')}}{{#test('Second')}}{{#end}}
>
> ends up a recurring mess because $bodyContent seems to be still defined when
> calling the inner macro without a block. I propose (perleeze) that it should
> always be unset when calling a macro without a block. It's fine if you always
> call with @ and supply an empty block, or unset it manually before the second
> call
> p.s.
> #@\{test} or #\{@test} doesn't work either
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-970) velocity-engine-core contains commons-io Maven descriptor
[ https://issues.apache.org/jira/browse/VELOCITY-970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson updated VELOCITY-970: Fix Version/s: (was: 2.4.1) (was: 2.4.2) > velocity-engine-core contains commons-io Maven descriptor > - > > Key: VELOCITY-970 > URL: https://issues.apache.org/jira/browse/VELOCITY-970 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.3 >Reporter: Thomas Mortagne >Assignee: Michael Osipov >Priority: Major > Fix For: 2.4 > > > commons-io is embedded in velocity-engine-core, which is OK from Java point > of view since its package is renamed (not causing any dependency problems). > The problem is that it contains the commons-io Maven descriptors at the > standard location (/META-INF/maven/commons-io/commons-io/), which is a > problem when you analyze JAR files to find what's in it because it ends up > being identified as a JAR exposing commons-io (which is not the case since > it's weaved). > Honestly, it feels very strange to embed commons-io in the first place given > that commons-lang for example is a transitive dependency, so I feel like the > simplest would just be to remove all the plumbing to embed and weave > commons-io and simply keep it as a regular transitive dependency. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-971) Upgrade to Parent 6
[ https://issues.apache.org/jira/browse/VELOCITY-971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson updated VELOCITY-971: Fix Version/s: (was: 2.4.1) (was: 2.4.2) > Upgrade to Parent 6 > --- > > Key: VELOCITY-971 > URL: https://issues.apache.org/jira/browse/VELOCITY-971 > Project: Velocity > Issue Type: Improvement > Components: Build >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 2.4 > > > Parent 6 gives us the ability to clean up a lot of duplicate stuff in our > POMs. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-981) Upgrade to Parent 7
[ https://issues.apache.org/jira/browse/VELOCITY-981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson updated VELOCITY-981: Fix Version/s: 2.4 > Upgrade to Parent 7 > --- > > Key: VELOCITY-981 > URL: https://issues.apache.org/jira/browse/VELOCITY-981 > Project: Velocity > Issue Type: Task > Components: Build >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 2.4, 2.4.2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [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 ] Sylwester Lachiewicz updated VELOCITY-977: -- Fix Version/s: 2.4 > 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.4.2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Resolved] (VELOCITY-943) File vs. classpath issues with Spring VelocityEngineFactory
[ https://issues.apache.org/jira/browse/VELOCITY-943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson resolved VELOCITY-943. - Fix Version/s: 2.4 Assignee: Claude Brisson Resolution: Fixed PR merged > File vs. classpath issues with Spring VelocityEngineFactory > --- > > Key: VELOCITY-943 > URL: https://issues.apache.org/jira/browse/VELOCITY-943 > Project: Velocity > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Scott Cantor >Assignee: Claude Brisson >Priority: Minor > Labels: spring > Fix For: 2.4 > > Attachments: VelocityEngineFactory.java > > > TL;DR, there's a nominal bug fix, and a possible improvement I can suggest, > for the Spring support you copied in from Spring 4 based on the copy we're > using in our project. Our copy differs in some slight ways so a straight > patch diff wasn't very obvious and I'm just going to attach our copy of the > file. > Full explanation: we ported the Spring support into our code for Spring 5 > before you had ported it in, and we were actually prepping a submission for > that but you pulled it in before we had a chance. There were some slight > improvements I made for our use, and today another issue in the same area of > the code got reported and fixed, and it's nominally a bug, so I thought I'd > try submitting that as a possible improvement along with my other change. > The issue is mainly around the way the Spring code combined use of the > File-based Velocity loader with the Spring loader by checking for filesystem > existence on the paths, in order to allow file-based usage to leverage > Velocity's support for template reloading. > In Spring's code (and now your code), there's an issue because it processes > each path via Spring ResourceLoader and then converts the Resource into a > File for an exists() test. If that passes, it installs the file-based loader > instead of the Spring loader. The problem/bug is that some containers unpack > jars, but only partially. Some kind of weird optimization I guess. The result > is that if some of the files get unpacked and not others, this code installs > the file loader and then that fails later because not all the files are there. > The fix seems to be to check for classpath: leading off the path and skip the > exists() check so that it will get deferred to the Spring loader. So that's a > fix, nominally, though right now we've only seen this reported for Wildfly as > a container. > The related enhancement I made was that I allowed for both File-based and > Spring-based paths by walking the complete list and tracking each path set > individually and allowing both loaders to get installed into the Velocity > engine. That was needed for us to support both file-based templates along > with system templates we ship in jars. So as it, we have to have that feature > and can't use the original Spring code, so I'm hoping with the possible > justification of a bug fix, you might take the other change also. > All of the differences that aren't cosmetic are in the > initVelocityResourceLoader method, except that there's also a fix to > initSpringResourceLoader that changes a setProperty to addProperty so that > the Spring loader can get added to the set of loaders and not replace the > file loader. > Apologies that a diff would be so messy but hopefully given that the class is > simple and small, the differences will be clear enough with my explanation. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-943) File vs. classpath issues with Spring VelocityEngineFactory
[ https://issues.apache.org/jira/browse/VELOCITY-943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17879112#comment-17879112 ] Claude Brisson commented on VELOCITY-943: - Thanks for your remarks. Regarding VelocityView and ViewResolver, they should be part of a new module in the tools subproject, velocity-tools-spring or alike... Yes, only having the spring specialization for the engine itself is half of what's needed. > File vs. classpath issues with Spring VelocityEngineFactory > --- > > Key: VELOCITY-943 > URL: https://issues.apache.org/jira/browse/VELOCITY-943 > Project: Velocity > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Scott Cantor >Priority: Minor > Labels: spring > Attachments: VelocityEngineFactory.java > > > TL;DR, there's a nominal bug fix, and a possible improvement I can suggest, > for the Spring support you copied in from Spring 4 based on the copy we're > using in our project. Our copy differs in some slight ways so a straight > patch diff wasn't very obvious and I'm just going to attach our copy of the > file. > Full explanation: we ported the Spring support into our code for Spring 5 > before you had ported it in, and we were actually prepping a submission for > that but you pulled it in before we had a chance. There were some slight > improvements I made for our use, and today another issue in the same area of > the code got reported and fixed, and it's nominally a bug, so I thought I'd > try submitting that as a possible improvement along with my other change. > The issue is mainly around the way the Spring code combined use of the > File-based Velocity loader with the Spring loader by checking for filesystem > existence on the paths, in order to allow file-based usage to leverage > Velocity's support for template reloading. > In Spring's code (and now your code), there's an issue because it processes > each path via Spring ResourceLoader and then converts the Resource into a > File for an exists() test. If that passes, it installs the file-based loader > instead of the Spring loader. The problem/bug is that some containers unpack > jars, but only partially. Some kind of weird optimization I guess. The result > is that if some of the files get unpacked and not others, this code installs > the file loader and then that fails later because not all the files are there. > The fix seems to be to check for classpath: leading off the path and skip the > exists() check so that it will get deferred to the Spring loader. So that's a > fix, nominally, though right now we've only seen this reported for Wildfly as > a container. > The related enhancement I made was that I allowed for both File-based and > Spring-based paths by walking the complete list and tracking each path set > individually and allowing both loaders to get installed into the Velocity > engine. That was needed for us to support both file-based templates along > with system templates we ship in jars. So as it, we have to have that feature > and can't use the original Spring code, so I'm hoping with the possible > justification of a bug fix, you might take the other change also. > All of the differences that aren't cosmetic are in the > initVelocityResourceLoader method, except that there's also a fix to > initSpringResourceLoader that changes a setProperty to addProperty so that > the Spring loader can get added to the set of loaders and not replace the > file loader. > Apologies that a diff would be so messy but hopefully given that the class is > simple and small, the differences will be clear enough with my explanation. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-943) File vs. classpath issues with Spring VelocityEngineFactory
[ https://issues.apache.org/jira/browse/VELOCITY-943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17879043#comment-17879043 ] Scott Cantor commented on VELOCITY-943: --- I guess to more directly speak to the idea...yes, I could envision a dedicated SpringResourceLoader and SpringResourceLoaderEx where one of them was strictly Spring and the other allowed joint use of the File loader from original Velocity by "failing" over to the Spring one. That's probably more along the lines of your suggestion. But in terms of actually implementing it, that's a bigger change/risk and just more complex overall I think. I really don't think the extra logic I added is needed, it would be best to just say the original was broken for the cases it was trying to solve for and just fix it without the extra flag guarding the fix. > File vs. classpath issues with Spring VelocityEngineFactory > --- > > Key: VELOCITY-943 > URL: https://issues.apache.org/jira/browse/VELOCITY-943 > Project: Velocity > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Scott Cantor >Priority: Minor > Labels: spring > Attachments: VelocityEngineFactory.java > > > TL;DR, there's a nominal bug fix, and a possible improvement I can suggest, > for the Spring support you copied in from Spring 4 based on the copy we're > using in our project. Our copy differs in some slight ways so a straight > patch diff wasn't very obvious and I'm just going to attach our copy of the > file. > Full explanation: we ported the Spring support into our code for Spring 5 > before you had ported it in, and we were actually prepping a submission for > that but you pulled it in before we had a chance. There were some slight > improvements I made for our use, and today another issue in the same area of > the code got reported and fixed, and it's nominally a bug, so I thought I'd > try submitting that as a possible improvement along with my other change. > The issue is mainly around the way the Spring code combined use of the > File-based Velocity loader with the Spring loader by checking for filesystem > existence on the paths, in order to allow file-based usage to leverage > Velocity's support for template reloading. > In Spring's code (and now your code), there's an issue because it processes > each path via Spring ResourceLoader and then converts the Resource into a > File for an exists() test. If that passes, it installs the file-based loader > instead of the Spring loader. The problem/bug is that some containers unpack > jars, but only partially. Some kind of weird optimization I guess. The result > is that if some of the files get unpacked and not others, this code installs > the file loader and then that fails later because not all the files are there. > The fix seems to be to check for classpath: leading off the path and skip the > exists() check so that it will get deferred to the Spring loader. So that's a > fix, nominally, though right now we've only seen this reported for Wildfly as > a container. > The related enhancement I made was that I allowed for both File-based and > Spring-based paths by walking the complete list and tracking each path set > individually and allowing both loaders to get installed into the Velocity > engine. That was needed for us to support both file-based templates along > with system templates we ship in jars. So as it, we have to have that feature > and can't use the original Spring code, so I'm hoping with the possible > justification of a bug fix, you might take the other change also. > All of the differences that aren't cosmetic are in the > initVelocityResourceLoader method, except that there's also a fix to > initSpringResourceLoader that changes a setProperty to addProperty so that > the Spring loader can get added to the set of loaders and not replace the > file loader. > Apologies that a diff would be so messy but hopefully given that the class is > simple and small, the differences will be clear enough with my explanation. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-943) File vs. classpath issues with Spring VelocityEngineFactory
[ https://issues.apache.org/jira/browse/VELOCITY-943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17879040#comment-17879040 ] Scott Cantor edited comment on VELOCITY-943 at 9/3/24 9:56 PM: --- I actually noticed something else, which is what I'm not seeing the VelocityView and ViewResolver classes needed for this to actually be useful in Spring. Without those classes, it's pretty unlikely anybody could be using this anyway. I may just be overlooking them but I haven't found them yet. I guess Spring might have retained those classes, but that would be kind of odd if they were really meaning to dump all the Velocity code. was (Author: canto...@osu.edu): I actually noticed something else, which is what I'm not seeing the VelocityView and ViewResolver classes needed for this to actually be useful in Spring. Without those classes, it's pretty unlikely anybody could be using this anyway. I may just be overlooking them but I haven't found them yet. > File vs. classpath issues with Spring VelocityEngineFactory > --- > > Key: VELOCITY-943 > URL: https://issues.apache.org/jira/browse/VELOCITY-943 > Project: Velocity > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Scott Cantor >Priority: Minor > Labels: spring > Attachments: VelocityEngineFactory.java > > > TL;DR, there's a nominal bug fix, and a possible improvement I can suggest, > for the Spring support you copied in from Spring 4 based on the copy we're > using in our project. Our copy differs in some slight ways so a straight > patch diff wasn't very obvious and I'm just going to attach our copy of the > file. > Full explanation: we ported the Spring support into our code for Spring 5 > before you had ported it in, and we were actually prepping a submission for > that but you pulled it in before we had a chance. There were some slight > improvements I made for our use, and today another issue in the same area of > the code got reported and fixed, and it's nominally a bug, so I thought I'd > try submitting that as a possible improvement along with my other change. > The issue is mainly around the way the Spring code combined use of the > File-based Velocity loader with the Spring loader by checking for filesystem > existence on the paths, in order to allow file-based usage to leverage > Velocity's support for template reloading. > In Spring's code (and now your code), there's an issue because it processes > each path via Spring ResourceLoader and then converts the Resource into a > File for an exists() test. If that passes, it installs the file-based loader > instead of the Spring loader. The problem/bug is that some containers unpack > jars, but only partially. Some kind of weird optimization I guess. The result > is that if some of the files get unpacked and not others, this code installs > the file loader and then that fails later because not all the files are there. > The fix seems to be to check for classpath: leading off the path and skip the > exists() check so that it will get deferred to the Spring loader. So that's a > fix, nominally, though right now we've only seen this reported for Wildfly as > a container. > The related enhancement I made was that I allowed for both File-based and > Spring-based paths by walking the complete list and tracking each path set > individually and allowing both loaders to get installed into the Velocity > engine. That was needed for us to support both file-based templates along > with system templates we ship in jars. So as it, we have to have that feature > and can't use the original Spring code, so I'm hoping with the possible > justification of a bug fix, you might take the other change also. > All of the differences that aren't cosmetic are in the > initVelocityResourceLoader method, except that there's also a fix to > initSpringResourceLoader that changes a setProperty to addProperty so that > the Spring loader can get added to the set of loaders and not replace the > file loader. > Apologies that a diff would be so messy but hopefully given that the class is > simple and small, the differences will be clear enough with my explanation. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-943) File vs. classpath issues with Spring VelocityEngineFactory
[ https://issues.apache.org/jira/browse/VELOCITY-943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17879040#comment-17879040 ] Scott Cantor commented on VELOCITY-943: --- I actually noticed something else, which is what I'm not seeing the VelocityView and ViewResolver classes needed for this to actually be useful in Spring. Without those classes, it's pretty unlikely anybody could be using this anyway. I may just be overlooking them but I haven't found them yet. > File vs. classpath issues with Spring VelocityEngineFactory > --- > > Key: VELOCITY-943 > URL: https://issues.apache.org/jira/browse/VELOCITY-943 > Project: Velocity > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Scott Cantor >Priority: Minor > Labels: spring > Attachments: VelocityEngineFactory.java > > > TL;DR, there's a nominal bug fix, and a possible improvement I can suggest, > for the Spring support you copied in from Spring 4 based on the copy we're > using in our project. Our copy differs in some slight ways so a straight > patch diff wasn't very obvious and I'm just going to attach our copy of the > file. > Full explanation: we ported the Spring support into our code for Spring 5 > before you had ported it in, and we were actually prepping a submission for > that but you pulled it in before we had a chance. There were some slight > improvements I made for our use, and today another issue in the same area of > the code got reported and fixed, and it's nominally a bug, so I thought I'd > try submitting that as a possible improvement along with my other change. > The issue is mainly around the way the Spring code combined use of the > File-based Velocity loader with the Spring loader by checking for filesystem > existence on the paths, in order to allow file-based usage to leverage > Velocity's support for template reloading. > In Spring's code (and now your code), there's an issue because it processes > each path via Spring ResourceLoader and then converts the Resource into a > File for an exists() test. If that passes, it installs the file-based loader > instead of the Spring loader. The problem/bug is that some containers unpack > jars, but only partially. Some kind of weird optimization I guess. The result > is that if some of the files get unpacked and not others, this code installs > the file loader and then that fails later because not all the files are there. > The fix seems to be to check for classpath: leading off the path and skip the > exists() check so that it will get deferred to the Spring loader. So that's a > fix, nominally, though right now we've only seen this reported for Wildfly as > a container. > The related enhancement I made was that I allowed for both File-based and > Spring-based paths by walking the complete list and tracking each path set > individually and allowing both loaders to get installed into the Velocity > engine. That was needed for us to support both file-based templates along > with system templates we ship in jars. So as it, we have to have that feature > and can't use the original Spring code, so I'm hoping with the possible > justification of a bug fix, you might take the other change also. > All of the differences that aren't cosmetic are in the > initVelocityResourceLoader method, except that there's also a fix to > initSpringResourceLoader that changes a setProperty to addProperty so that > the Spring loader can get added to the set of loaders and not replace the > file loader. > Apologies that a diff would be so messy but hopefully given that the class is > simple and small, the differences will be clear enough with my explanation. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-943) File vs. classpath issues with Spring VelocityEngineFactory
[ https://issues.apache.org/jira/browse/VELOCITY-943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17879039#comment-17879039 ] Scott Cantor commented on VELOCITY-943: --- It does that now, the original file-based one is used in place of the Spring loader in many cases. The problem is that it's either/or, which is not really useful, whereas my patch just makes them both work in parallel (with the new flag set anyway). My argument is basically that if you didn't want the Spring loader, you wouldn't configure it in the first place. Bear in mind, this code isn't the thing implementing the Spring loader. That's a different class. This code is used to auto-configure a Velocity engine with the "right" resource loader(s) based on a set of resource paths. It's making a decision about which loader(s) to install. The original version picks between them (improperly) and only gives you one. My patch just allows them both to be installed. The other way this would be done is by having people manually configure their own VelocityEngine with exactly the loaders they want and the paths to use. I think that's already probably possible without this class, this is just a shorthand for that so you can hand it a big path and let it figure out what to do. It would be entirely defensible to just say "forget about files here", and then the class probably just goes away, but for whatever reason the original author tried to make it "smarter" and didn't do that correctly in a few different respects. > File vs. classpath issues with Spring VelocityEngineFactory > --- > > Key: VELOCITY-943 > URL: https://issues.apache.org/jira/browse/VELOCITY-943 > Project: Velocity > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Scott Cantor >Priority: Minor > Labels: spring > Attachments: VelocityEngineFactory.java > > > TL;DR, there's a nominal bug fix, and a possible improvement I can suggest, > for the Spring support you copied in from Spring 4 based on the copy we're > using in our project. Our copy differs in some slight ways so a straight > patch diff wasn't very obvious and I'm just going to attach our copy of the > file. > Full explanation: we ported the Spring support into our code for Spring 5 > before you had ported it in, and we were actually prepping a submission for > that but you pulled it in before we had a chance. There were some slight > improvements I made for our use, and today another issue in the same area of > the code got reported and fixed, and it's nominally a bug, so I thought I'd > try submitting that as a possible improvement along with my other change. > The issue is mainly around the way the Spring code combined use of the > File-based Velocity loader with the Spring loader by checking for filesystem > existence on the paths, in order to allow file-based usage to leverage > Velocity's support for template reloading. > In Spring's code (and now your code), there's an issue because it processes > each path via Spring ResourceLoader and then converts the Resource into a > File for an exists() test. If that passes, it installs the file-based loader > instead of the Spring loader. The problem/bug is that some containers unpack > jars, but only partially. Some kind of weird optimization I guess. The result > is that if some of the files get unpacked and not others, this code installs > the file loader and then that fails later because not all the files are there. > The fix seems to be to check for classpath: leading off the path and skip the > exists() check so that it will get deferred to the Spring loader. So that's a > fix, nominally, though right now we've only seen this reported for Wildfly as > a container. > The related enhancement I made was that I allowed for both File-based and > Spring-based paths by walking the complete list and tracking each path set > individually and allowing both loaders to get installed into the Velocity > engine. That was needed for us to support both file-based templates along > with system templates we ship in jars. So as it, we have to have that feature > and can't use the original Spring code, so I'm hoping with the possible > justification of a bug fix, you might take the other change also. > All of the differences that aren't cosmetic are in the > initVelocityResourceLoader method, except that there's also a fix to > initSpringResourceLoader that changes a setProperty to addProperty so tha
[jira] [Commented] (VELOCITY-943) File vs. classpath issues with Spring VelocityEngineFactory
[ https://issues.apache.org/jira/browse/VELOCITY-943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17879027#comment-17879027 ] Claude Brisson commented on VELOCITY-943: - Thanks for your prompt answer and contribution. Would that make sense and bring simplicity to handle that specific distinguo between file entries and classpath entries by means of having two distinct resource loaders, one explicitly searching for files and the other for classpath entries? > File vs. classpath issues with Spring VelocityEngineFactory > --- > > Key: VELOCITY-943 > URL: https://issues.apache.org/jira/browse/VELOCITY-943 > Project: Velocity > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Scott Cantor >Priority: Minor > Labels: spring > Attachments: VelocityEngineFactory.java > > > TL;DR, there's a nominal bug fix, and a possible improvement I can suggest, > for the Spring support you copied in from Spring 4 based on the copy we're > using in our project. Our copy differs in some slight ways so a straight > patch diff wasn't very obvious and I'm just going to attach our copy of the > file. > Full explanation: we ported the Spring support into our code for Spring 5 > before you had ported it in, and we were actually prepping a submission for > that but you pulled it in before we had a chance. There were some slight > improvements I made for our use, and today another issue in the same area of > the code got reported and fixed, and it's nominally a bug, so I thought I'd > try submitting that as a possible improvement along with my other change. > The issue is mainly around the way the Spring code combined use of the > File-based Velocity loader with the Spring loader by checking for filesystem > existence on the paths, in order to allow file-based usage to leverage > Velocity's support for template reloading. > In Spring's code (and now your code), there's an issue because it processes > each path via Spring ResourceLoader and then converts the Resource into a > File for an exists() test. If that passes, it installs the file-based loader > instead of the Spring loader. The problem/bug is that some containers unpack > jars, but only partially. Some kind of weird optimization I guess. The result > is that if some of the files get unpacked and not others, this code installs > the file loader and then that fails later because not all the files are there. > The fix seems to be to check for classpath: leading off the path and skip the > exists() check so that it will get deferred to the Spring loader. So that's a > fix, nominally, though right now we've only seen this reported for Wildfly as > a container. > The related enhancement I made was that I allowed for both File-based and > Spring-based paths by walking the complete list and tracking each path set > individually and allowing both loaders to get installed into the Velocity > engine. That was needed for us to support both file-based templates along > with system templates we ship in jars. So as it, we have to have that feature > and can't use the original Spring code, so I'm hoping with the possible > justification of a bug fix, you might take the other change also. > All of the differences that aren't cosmetic are in the > initVelocityResourceLoader method, except that there's also a fix to > initSpringResourceLoader that changes a setProperty to addProperty so that > the Spring loader can get added to the set of loaders and not replace the > file loader. > Apologies that a diff would be so messy but hopefully given that the class is > simple and small, the differences will be clear enough with my explanation. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-943) File vs. classpath issues with Spring VelocityEngineFactory
[ https://issues.apache.org/jira/browse/VELOCITY-943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878951#comment-17878951 ] Scott Cantor edited comment on VELOCITY-943 at 9/3/24 5:42 PM: --- I kind of bum-rushed this, but here's a PR out of GitHub: https://github.com/apache/velocity-engine/pull/51 I think this does what you want, but at a cost of some complication. I'm not honestly sure it's warranted, the original behavior isn't really "a way of doing something", it's just broken. But I added a flag to the VelocityEngineFactory class for "supporting enhanced classpath processing" that tries to fall back to the older/broken behavior. Basically, the old code puts in either a Spring or File-based resource loader depending on what sorts of paths it encounters. The new code conditionally allows both types to be installed for the appropriate path types based on how the original logic did that, but with a callout for classpath: resource URLs. Ultimately, and this is why I don't think this is really a "change", it comes down to what paths you include. If you deliberately include both file and classpath locations in your loader path, the old code isn't going to work. If you don't include both, then this devolves to the original behavior anyway since it's only going to install one or the other type of paths. So if you're asking me as a Spring user, the right answer would be for me to simplify the patch back to "just do the right thing" based on what the paths turn out to be. was (Author: canto...@osu.edu): I kind of bum-rushed this, but here's a PR out of GitHub: https://github.com/apache/velocity-engine/pull/51 I think this does what you want, but at a cost of some complication. I'm not honestly sure it's warranted, the original behavior isn't really "a way of doing something", it's just broken. But I added a flag to the VelocityEngineFactory class for "supporting enhanced classpath processing" that tries to fall back to the older/broken behavior. Basically, the old code puts in either a Spring or File-based resource loader depending on what sorts of paths it encounters. The new code conditionally allows both types to be installed for the appropriate path types based on how the original logic did that, but with a callout for classpath: resource URLs. Ultimately, and this is why I don't think this is really a "change", it comes down to what paths you include. If you deliberately include both file and classpath locations in your loader path, the old code isn't going to work. If you don't include both, then this devolves to the original behavior anyway since it's only going to install one or the other type of paths. So if you're asking me as a Spring user, the right answer would be for me to simplify the path back to "just do the right thing" based on what the paths turn out to be. > File vs. classpath issues with Spring VelocityEngineFactory > --- > > Key: VELOCITY-943 > URL: https://issues.apache.org/jira/browse/VELOCITY-943 > Project: Velocity > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Scott Cantor >Priority: Minor > Labels: spring > Attachments: VelocityEngineFactory.java > > > TL;DR, there's a nominal bug fix, and a possible improvement I can suggest, > for the Spring support you copied in from Spring 4 based on the copy we're > using in our project. Our copy differs in some slight ways so a straight > patch diff wasn't very obvious and I'm just going to attach our copy of the > file. > Full explanation: we ported the Spring support into our code for Spring 5 > before you had ported it in, and we were actually prepping a submission for > that but you pulled it in before we had a chance. There were some slight > improvements I made for our use, and today another issue in the same area of > the code got reported and fixed, and it's nominally a bug, so I thought I'd > try submitting that as a possible improvement along with my other change. > The issue is mainly around the way the Spring code combined use of the > File-based Velocity loader with the Spring loader by checking for filesystem > existence on the paths, in order to allow file-based usage to leverage > Velocity's support for template reloading. > In Spring's code (and now your code), there's an issue because it processes > each path via Spring ResourceLoader and then converts the Resource into
[jira] [Comment Edited] (VELOCITY-943) File vs. classpath issues with Spring VelocityEngineFactory
[ https://issues.apache.org/jira/browse/VELOCITY-943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878951#comment-17878951 ] Scott Cantor edited comment on VELOCITY-943 at 9/3/24 5:41 PM: --- I kind of bum-rushed this, but here's a PR out of GitHub: https://github.com/apache/velocity-engine/pull/51 I think this does what you want, but at a cost of some complication. I'm not honestly sure it's warranted, the original behavior isn't really "a way of doing something", it's just broken. But I added a flag to the VelocityEngineFactory class for "supporting enhanced classpath processing" that tries to fall back to the older/broken behavior. Basically, the old code puts in either a Spring or File-based resource loader depending on what sorts of paths it encounters. The new code conditionally allows both types to be installed for the appropriate path types based on how the original logic did that, but with a callout for classpath: resource URLs. Ultimately, and this is why I don't think this is really a "change", it comes down to what paths you include. If you deliberately include both file and classpath locations in your loader path, the old code isn't going to work. If you don't include both, then this devolves to the original behavior anyway since it's only going to install one or the other type of paths. So if you're asking me as a Spring user, the right answer would be for me to simplify the path back to "just do the right thing" based on what the paths turn out to be. was (Author: canto...@osu.edu): I kind of bum-rushed this, but here's a PR out of GitHub: https://github.com/apache/velocity-engine/pull/51 I think this does what you want, but at a cost of some complication. I'm not honestly sure it's warranted, the original behavior isn't really "a way of doing something", it's just broken. But I added a flag to the VelocityEngineFactory class for "supporting enhanced classpath processing" that tries to fall back to the older/broken behavior. Basically, the old code puts in either a Spring or File-based resource loader depending on what sorts of paths it encounters. The new code conditionally allows both types to be installed for the appropriate path types based on how the original logic did that, but with a callout for classpath: resource URLs. > File vs. classpath issues with Spring VelocityEngineFactory > --- > > Key: VELOCITY-943 > URL: https://issues.apache.org/jira/browse/VELOCITY-943 > Project: Velocity > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Scott Cantor >Priority: Minor > Labels: spring > Attachments: VelocityEngineFactory.java > > > TL;DR, there's a nominal bug fix, and a possible improvement I can suggest, > for the Spring support you copied in from Spring 4 based on the copy we're > using in our project. Our copy differs in some slight ways so a straight > patch diff wasn't very obvious and I'm just going to attach our copy of the > file. > Full explanation: we ported the Spring support into our code for Spring 5 > before you had ported it in, and we were actually prepping a submission for > that but you pulled it in before we had a chance. There were some slight > improvements I made for our use, and today another issue in the same area of > the code got reported and fixed, and it's nominally a bug, so I thought I'd > try submitting that as a possible improvement along with my other change. > The issue is mainly around the way the Spring code combined use of the > File-based Velocity loader with the Spring loader by checking for filesystem > existence on the paths, in order to allow file-based usage to leverage > Velocity's support for template reloading. > In Spring's code (and now your code), there's an issue because it processes > each path via Spring ResourceLoader and then converts the Resource into a > File for an exists() test. If that passes, it installs the file-based loader > instead of the Spring loader. The problem/bug is that some containers unpack > jars, but only partially. Some kind of weird optimization I guess. The result > is that if some of the files get unpacked and not others, this code installs > the file loader and then that fails later because not all the files are there. > The fix seems to be to check for classpath: leading off the path and skip the > exists() check so that it will get deferred to the Spring loader. So that's a >
[jira] (VELOCITY-943) File vs. classpath issues with Spring VelocityEngineFactory
[ https://issues.apache.org/jira/browse/VELOCITY-943 ] Scott Cantor deleted comment on VELOCITY-943: --- was (Author: canto...@osu.edu): Oh, probably not soon. It could be this month if thinigs shift, but later this year is much more likely. > File vs. classpath issues with Spring VelocityEngineFactory > --- > > Key: VELOCITY-943 > URL: https://issues.apache.org/jira/browse/VELOCITY-943 > Project: Velocity > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Scott Cantor >Priority: Minor > Labels: spring > Attachments: VelocityEngineFactory.java > > > TL;DR, there's a nominal bug fix, and a possible improvement I can suggest, > for the Spring support you copied in from Spring 4 based on the copy we're > using in our project. Our copy differs in some slight ways so a straight > patch diff wasn't very obvious and I'm just going to attach our copy of the > file. > Full explanation: we ported the Spring support into our code for Spring 5 > before you had ported it in, and we were actually prepping a submission for > that but you pulled it in before we had a chance. There were some slight > improvements I made for our use, and today another issue in the same area of > the code got reported and fixed, and it's nominally a bug, so I thought I'd > try submitting that as a possible improvement along with my other change. > The issue is mainly around the way the Spring code combined use of the > File-based Velocity loader with the Spring loader by checking for filesystem > existence on the paths, in order to allow file-based usage to leverage > Velocity's support for template reloading. > In Spring's code (and now your code), there's an issue because it processes > each path via Spring ResourceLoader and then converts the Resource into a > File for an exists() test. If that passes, it installs the file-based loader > instead of the Spring loader. The problem/bug is that some containers unpack > jars, but only partially. Some kind of weird optimization I guess. The result > is that if some of the files get unpacked and not others, this code installs > the file loader and then that fails later because not all the files are there. > The fix seems to be to check for classpath: leading off the path and skip the > exists() check so that it will get deferred to the Spring loader. So that's a > fix, nominally, though right now we've only seen this reported for Wildfly as > a container. > The related enhancement I made was that I allowed for both File-based and > Spring-based paths by walking the complete list and tracking each path set > individually and allowing both loaders to get installed into the Velocity > engine. That was needed for us to support both file-based templates along > with system templates we ship in jars. So as it, we have to have that feature > and can't use the original Spring code, so I'm hoping with the possible > justification of a bug fix, you might take the other change also. > All of the differences that aren't cosmetic are in the > initVelocityResourceLoader method, except that there's also a fix to > initSpringResourceLoader that changes a setProperty to addProperty so that > the Spring loader can get added to the set of loaders and not replace the > file loader. > Apologies that a diff would be so messy but hopefully given that the class is > simple and small, the differences will be clear enough with my explanation. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-943) File vs. classpath issues with Spring VelocityEngineFactory
[ https://issues.apache.org/jira/browse/VELOCITY-943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878951#comment-17878951 ] Scott Cantor commented on VELOCITY-943: --- I kind of bum-rushed this, but here's a PR out of GitHub: https://github.com/apache/velocity-engine/pull/51 I think this does what you want, but at a cost of some complication. I'm not honestly sure it's warranted, the original behavior isn't really "a way of doing something", it's just broken. But I added a flag to the VelocityEngineFactory class for "supporting enhanced classpath processing" that tries to fall back to the older/broken behavior. Basically, the old code puts in either a Spring or File-based resource loader depending on what sorts of paths it encounters. The new code conditionally allows both types to be installed for the appropriate path types based on how the original logic did that, but with a callout for classpath: resource URLs. > File vs. classpath issues with Spring VelocityEngineFactory > --- > > Key: VELOCITY-943 > URL: https://issues.apache.org/jira/browse/VELOCITY-943 > Project: Velocity > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Scott Cantor >Priority: Minor > Labels: spring > Attachments: VelocityEngineFactory.java > > > TL;DR, there's a nominal bug fix, and a possible improvement I can suggest, > for the Spring support you copied in from Spring 4 based on the copy we're > using in our project. Our copy differs in some slight ways so a straight > patch diff wasn't very obvious and I'm just going to attach our copy of the > file. > Full explanation: we ported the Spring support into our code for Spring 5 > before you had ported it in, and we were actually prepping a submission for > that but you pulled it in before we had a chance. There were some slight > improvements I made for our use, and today another issue in the same area of > the code got reported and fixed, and it's nominally a bug, so I thought I'd > try submitting that as a possible improvement along with my other change. > The issue is mainly around the way the Spring code combined use of the > File-based Velocity loader with the Spring loader by checking for filesystem > existence on the paths, in order to allow file-based usage to leverage > Velocity's support for template reloading. > In Spring's code (and now your code), there's an issue because it processes > each path via Spring ResourceLoader and then converts the Resource into a > File for an exists() test. If that passes, it installs the file-based loader > instead of the Spring loader. The problem/bug is that some containers unpack > jars, but only partially. Some kind of weird optimization I guess. The result > is that if some of the files get unpacked and not others, this code installs > the file loader and then that fails later because not all the files are there. > The fix seems to be to check for classpath: leading off the path and skip the > exists() check so that it will get deferred to the Spring loader. So that's a > fix, nominally, though right now we've only seen this reported for Wildfly as > a container. > The related enhancement I made was that I allowed for both File-based and > Spring-based paths by walking the complete list and tracking each path set > individually and allowing both loaders to get installed into the Velocity > engine. That was needed for us to support both file-based templates along > with system templates we ship in jars. So as it, we have to have that feature > and can't use the original Spring code, so I'm hoping with the possible > justification of a bug fix, you might take the other change also. > All of the differences that aren't cosmetic are in the > initVelocityResourceLoader method, except that there's also a fix to > initSpringResourceLoader that changes a setProperty to addProperty so that > the Spring loader can get added to the set of loaders and not replace the > file loader. > Apologies that a diff would be so messy but hopefully given that the class is > simple and small, the differences will be clear enough with my explanation. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] (VELOCITY-943) File vs. classpath issues with Spring VelocityEngineFactory
[ https://issues.apache.org/jira/browse/VELOCITY-943 ] Scott Cantor deleted comment on VELOCITY-943: --- was (Author: canto...@osu.edu): If I can escalate the work, when would I need to prep a patch in time for? > File vs. classpath issues with Spring VelocityEngineFactory > --- > > Key: VELOCITY-943 > URL: https://issues.apache.org/jira/browse/VELOCITY-943 > Project: Velocity > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Scott Cantor >Priority: Minor > Labels: spring > Attachments: VelocityEngineFactory.java > > > TL;DR, there's a nominal bug fix, and a possible improvement I can suggest, > for the Spring support you copied in from Spring 4 based on the copy we're > using in our project. Our copy differs in some slight ways so a straight > patch diff wasn't very obvious and I'm just going to attach our copy of the > file. > Full explanation: we ported the Spring support into our code for Spring 5 > before you had ported it in, and we were actually prepping a submission for > that but you pulled it in before we had a chance. There were some slight > improvements I made for our use, and today another issue in the same area of > the code got reported and fixed, and it's nominally a bug, so I thought I'd > try submitting that as a possible improvement along with my other change. > The issue is mainly around the way the Spring code combined use of the > File-based Velocity loader with the Spring loader by checking for filesystem > existence on the paths, in order to allow file-based usage to leverage > Velocity's support for template reloading. > In Spring's code (and now your code), there's an issue because it processes > each path via Spring ResourceLoader and then converts the Resource into a > File for an exists() test. If that passes, it installs the file-based loader > instead of the Spring loader. The problem/bug is that some containers unpack > jars, but only partially. Some kind of weird optimization I guess. The result > is that if some of the files get unpacked and not others, this code installs > the file loader and then that fails later because not all the files are there. > The fix seems to be to check for classpath: leading off the path and skip the > exists() check so that it will get deferred to the Spring loader. So that's a > fix, nominally, though right now we've only seen this reported for Wildfly as > a container. > The related enhancement I made was that I allowed for both File-based and > Spring-based paths by walking the complete list and tracking each path set > individually and allowing both loaders to get installed into the Velocity > engine. That was needed for us to support both file-based templates along > with system templates we ship in jars. So as it, we have to have that feature > and can't use the original Spring code, so I'm hoping with the possible > justification of a bug fix, you might take the other change also. > All of the differences that aren't cosmetic are in the > initVelocityResourceLoader method, except that there's also a fix to > initSpringResourceLoader that changes a setProperty to addProperty so that > the Spring loader can get added to the set of loaders and not replace the > file loader. > Apologies that a diff would be so messy but hopefully given that the class is > simple and small, the differences will be clear enough with my explanation. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-943) File vs. classpath issues with Spring VelocityEngineFactory
[ https://issues.apache.org/jira/browse/VELOCITY-943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878916#comment-17878916 ] Scott Cantor commented on VELOCITY-943: --- If I can escalate the work, when would I need to prep a patch in time for? > File vs. classpath issues with Spring VelocityEngineFactory > --- > > Key: VELOCITY-943 > URL: https://issues.apache.org/jira/browse/VELOCITY-943 > Project: Velocity > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Scott Cantor >Priority: Minor > Labels: spring > Attachments: VelocityEngineFactory.java > > > TL;DR, there's a nominal bug fix, and a possible improvement I can suggest, > for the Spring support you copied in from Spring 4 based on the copy we're > using in our project. Our copy differs in some slight ways so a straight > patch diff wasn't very obvious and I'm just going to attach our copy of the > file. > Full explanation: we ported the Spring support into our code for Spring 5 > before you had ported it in, and we were actually prepping a submission for > that but you pulled it in before we had a chance. There were some slight > improvements I made for our use, and today another issue in the same area of > the code got reported and fixed, and it's nominally a bug, so I thought I'd > try submitting that as a possible improvement along with my other change. > The issue is mainly around the way the Spring code combined use of the > File-based Velocity loader with the Spring loader by checking for filesystem > existence on the paths, in order to allow file-based usage to leverage > Velocity's support for template reloading. > In Spring's code (and now your code), there's an issue because it processes > each path via Spring ResourceLoader and then converts the Resource into a > File for an exists() test. If that passes, it installs the file-based loader > instead of the Spring loader. The problem/bug is that some containers unpack > jars, but only partially. Some kind of weird optimization I guess. The result > is that if some of the files get unpacked and not others, this code installs > the file loader and then that fails later because not all the files are there. > The fix seems to be to check for classpath: leading off the path and skip the > exists() check so that it will get deferred to the Spring loader. So that's a > fix, nominally, though right now we've only seen this reported for Wildfly as > a container. > The related enhancement I made was that I allowed for both File-based and > Spring-based paths by walking the complete list and tracking each path set > individually and allowing both loaders to get installed into the Velocity > engine. That was needed for us to support both file-based templates along > with system templates we ship in jars. So as it, we have to have that feature > and can't use the original Spring code, so I'm hoping with the possible > justification of a bug fix, you might take the other change also. > All of the differences that aren't cosmetic are in the > initVelocityResourceLoader method, except that there's also a fix to > initSpringResourceLoader that changes a setProperty to addProperty so that > the Spring loader can get added to the set of loaders and not replace the > file loader. > Apologies that a diff would be so messy but hopefully given that the class is > simple and small, the differences will be clear enough with my explanation. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-943) File vs. classpath issues with Spring VelocityEngineFactory
[ https://issues.apache.org/jira/browse/VELOCITY-943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878858#comment-17878858 ] Scott Cantor commented on VELOCITY-943: --- Oh, probably not soon. It could be this month if thinigs shift, but later this year is much more likely. > File vs. classpath issues with Spring VelocityEngineFactory > --- > > Key: VELOCITY-943 > URL: https://issues.apache.org/jira/browse/VELOCITY-943 > Project: Velocity > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Scott Cantor >Priority: Minor > Labels: spring > Attachments: VelocityEngineFactory.java > > > TL;DR, there's a nominal bug fix, and a possible improvement I can suggest, > for the Spring support you copied in from Spring 4 based on the copy we're > using in our project. Our copy differs in some slight ways so a straight > patch diff wasn't very obvious and I'm just going to attach our copy of the > file. > Full explanation: we ported the Spring support into our code for Spring 5 > before you had ported it in, and we were actually prepping a submission for > that but you pulled it in before we had a chance. There were some slight > improvements I made for our use, and today another issue in the same area of > the code got reported and fixed, and it's nominally a bug, so I thought I'd > try submitting that as a possible improvement along with my other change. > The issue is mainly around the way the Spring code combined use of the > File-based Velocity loader with the Spring loader by checking for filesystem > existence on the paths, in order to allow file-based usage to leverage > Velocity's support for template reloading. > In Spring's code (and now your code), there's an issue because it processes > each path via Spring ResourceLoader and then converts the Resource into a > File for an exists() test. If that passes, it installs the file-based loader > instead of the Spring loader. The problem/bug is that some containers unpack > jars, but only partially. Some kind of weird optimization I guess. The result > is that if some of the files get unpacked and not others, this code installs > the file loader and then that fails later because not all the files are there. > The fix seems to be to check for classpath: leading off the path and skip the > exists() check so that it will get deferred to the Spring loader. So that's a > fix, nominally, though right now we've only seen this reported for Wildfly as > a container. > The related enhancement I made was that I allowed for both File-based and > Spring-based paths by walking the complete list and tracking each path set > individually and allowing both loaders to get installed into the Velocity > engine. That was needed for us to support both file-based templates along > with system templates we ship in jars. So as it, we have to have that feature > and can't use the original Spring code, so I'm hoping with the possible > justification of a bug fix, you might take the other change also. > All of the differences that aren't cosmetic are in the > initVelocityResourceLoader method, except that there's also a fix to > initSpringResourceLoader that changes a setProperty to addProperty so that > the Spring loader can get added to the set of loaders and not replace the > file loader. > Apologies that a diff would be so messy but hopefully given that the class is > simple and small, the differences will be clear enough with my explanation. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-943) File vs. classpath issues with Spring VelocityEngineFactory
[ https://issues.apache.org/jira/browse/VELOCITY-943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878417#comment-17878417 ] Claude Brisson commented on VELOCITY-943: - Do you know when you will be able to provide this patch? We have a release in the pipe, should we wait for it? > File vs. classpath issues with Spring VelocityEngineFactory > --- > > Key: VELOCITY-943 > URL: https://issues.apache.org/jira/browse/VELOCITY-943 > Project: Velocity > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Scott Cantor >Priority: Minor > Labels: spring > Attachments: VelocityEngineFactory.java > > > TL;DR, there's a nominal bug fix, and a possible improvement I can suggest, > for the Spring support you copied in from Spring 4 based on the copy we're > using in our project. Our copy differs in some slight ways so a straight > patch diff wasn't very obvious and I'm just going to attach our copy of the > file. > Full explanation: we ported the Spring support into our code for Spring 5 > before you had ported it in, and we were actually prepping a submission for > that but you pulled it in before we had a chance. There were some slight > improvements I made for our use, and today another issue in the same area of > the code got reported and fixed, and it's nominally a bug, so I thought I'd > try submitting that as a possible improvement along with my other change. > The issue is mainly around the way the Spring code combined use of the > File-based Velocity loader with the Spring loader by checking for filesystem > existence on the paths, in order to allow file-based usage to leverage > Velocity's support for template reloading. > In Spring's code (and now your code), there's an issue because it processes > each path via Spring ResourceLoader and then converts the Resource into a > File for an exists() test. If that passes, it installs the file-based loader > instead of the Spring loader. The problem/bug is that some containers unpack > jars, but only partially. Some kind of weird optimization I guess. The result > is that if some of the files get unpacked and not others, this code installs > the file loader and then that fails later because not all the files are there. > The fix seems to be to check for classpath: leading off the path and skip the > exists() check so that it will get deferred to the Spring loader. So that's a > fix, nominally, though right now we've only seen this reported for Wildfly as > a container. > The related enhancement I made was that I allowed for both File-based and > Spring-based paths by walking the complete list and tracking each path set > individually and allowing both loaders to get installed into the Velocity > engine. That was needed for us to support both file-based templates along > with system templates we ship in jars. So as it, we have to have that feature > and can't use the original Spring code, so I'm hoping with the possible > justification of a bug fix, you might take the other change also. > All of the differences that aren't cosmetic are in the > initVelocityResourceLoader method, except that there's also a fix to > initSpringResourceLoader that changes a setProperty to addProperty so that > the Spring loader can get added to the set of loaders and not replace the > file loader. > Apologies that a diff would be so messy but hopefully given that the class is > simple and small, the differences will be clear enough with my explanation. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Closed] (VELOCITY-965) Velocity 1.7 vs velocity 2.3: Getting thread synchronization issue
[
https://issues.apache.org/jira/browse/VELOCITY-965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson closed VELOCITY-965.
---
Fix Version/s: 2.4
Assignee: Claude Brisson
Resolution: Fixed
See commit 6c85ffe2
> Velocity 1.7 vs velocity 2.3: Getting thread synchronization issue
> --
>
> Key: VELOCITY-965
> URL: https://issues.apache.org/jira/browse/VELOCITY-965
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Amrit
>Assignee: Claude Brisson
>Priority: Major
> Fix For: 2.4
>
>
> Recently we migrated from Velocity 1.7 to Velocity 2.3. We see the below
> error intermittently which is a possible thread synchronization issue with
> Velocity Engine. The resultset is getting closed while another thread is
> making use of it.
> {noformat}
> 2023-04-15 10:36:33.472 ERROR [org.apache.velocity.loader.ds]
> {344} - DataSourceResourceLoader: database problem while getting timestamp of
> 'xyz_abc':
> java.sql.SQLException: Closed Resultset: next
> at
> oracle.jdbc.driver.InsensitiveScrollableResultSet.ensureOpen(InsensitiveScrollableResultSet.java:109)
> ~[ojdbc8.jar:12.2.0.1.0]
> at
> oracle.jdbc.driver.InsensitiveScrollableResultSet.next(InsensitiveScrollableResultSet.java:398)
> ~[ojdbc8.jar:12.2.0.1.0]
> at
> weblogic.jdbc.wrapper.ResultSet_oracle_jdbc_driver_ForwardOnlyResultSet.next(Unknown
> Source) ~[CodeGenerator.class:12.2.1.3]
> at
> org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader.readLastModified(DataSourceResourceLoader.java:326)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader.getLastModified(DataSourceResourceLoader.java:240)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:446)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:346)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1677)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1656)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.app.VelocityEngine.getTemplate(VelocityEngine.java:314)
> ~[velocity-engine-core-2.3.jar:2.3]
> {noformat}
> Reference:
> https://stackoverflow.com/questions/2794167/is-resultset-thread-safe
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Closed] (VELOCITY-966) RuntimeInstance.render throws null pointer exception when trying to render the same AST
[
https://issues.apache.org/jira/browse/VELOCITY-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson closed VELOCITY-966.
---
Resolution: Not A Bug
> RuntimeInstance.render throws null pointer exception when trying to render
> the same AST
>
>
> Key: VELOCITY-966
> URL: https://issues.apache.org/jira/browse/VELOCITY-966
> Project: Velocity
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Alex
>Assignee: Claude Brisson
>Priority: Major
>
> The objective is to use
> *RuntimeInstance.parse* to get the parsed AST for some template and cache the
> AST.
> Then use *RuntimeInstance.render* multiple times to render the text.
>
> It appears that in version 2.3 {*}RuntimeInstance.{*}{*}render{*} invokes the
> Node.init call and at the end of the rendering clears the parser and tokens.
> On the next attempt to render init fails with the NullPointerException
> because tokens have been cleared.{*}{*}
>
> So you can not call *RuntimeInstance.render* on the same AST several times
> which seems to be the intent of this method...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-966) RuntimeInstance.render throws null pointer exception when trying to render the same AST
[
https://issues.apache.org/jira/browse/VELOCITY-966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878307#comment-17878307
]
Claude Brisson commented on VELOCITY-966:
-
I admit that the API is far from perfect, mostly because of backward
compatibility issues.
But the RuntimeInstance.render() method is *not* meant for a reuse of the AST
tree. I will add it to the doc.
What you should do, instead, is rely on the Resource and Template API, as
follow:
{code}
final RuntimeInstance runtimeInstance = new RuntimeInstance();
final VelocityContext context = new VelocityContext();
context.put("user", "abc");
final Template aTemplate = new Template();
aTemplate.setName("a_template");
aTemplate.setRuntimeServices(runtimeInstance);
final SimpleNode parsedTemplate = runtimeInstance.parse(new
StringReader("Hello $user !!!"), aTemplate);
aTemplate.setData(parsedTemplate);
aTemplate.initDocument();
//first time using parsed template
final StringWriter writer = new StringWriter();
aTemplate.merge(context, writer);
System.out.println(writer);
//second time using parsed template
final StringWriter writer2 = new StringWriter();
aTemplate.merge(context, writer2);
System.out.println(writer2);
{code}
> RuntimeInstance.render throws null pointer exception when trying to render
> the same AST
>
>
> Key: VELOCITY-966
> URL: https://issues.apache.org/jira/browse/VELOCITY-966
> Project: Velocity
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Alex
>Assignee: Claude Brisson
>Priority: Major
>
> The objective is to use
> *RuntimeInstance.parse* to get the parsed AST for some template and cache the
> AST.
> Then use *RuntimeInstance.render* multiple times to render the text.
>
> It appears that in version 2.3 {*}RuntimeInstance.{*}{*}render{*} invokes the
> Node.init call and at the end of the rendering clears the parser and tokens.
> On the next attempt to render init fails with the NullPointerException
> because tokens have been cleared.{*}{*}
>
> So you can not call *RuntimeInstance.render* on the same AST several times
> which seems to be the intent of this method...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Reopened] (VELOCITY-966) RuntimeInstance.render throws null pointer exception when trying to render the same AST
[
https://issues.apache.org/jira/browse/VELOCITY-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson reopened VELOCITY-966:
-
Assignee: Claude Brisson
> RuntimeInstance.render throws null pointer exception when trying to render
> the same AST
>
>
> Key: VELOCITY-966
> URL: https://issues.apache.org/jira/browse/VELOCITY-966
> Project: Velocity
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Alex
>Assignee: Claude Brisson
>Priority: Major
>
> The objective is to use
> *RuntimeInstance.parse* to get the parsed AST for some template and cache the
> AST.
> Then use *RuntimeInstance.render* multiple times to render the text.
>
> It appears that in version 2.3 {*}RuntimeInstance.{*}{*}render{*} invokes the
> Node.init call and at the end of the rendering clears the parser and tokens.
> On the next attempt to render init fails with the NullPointerException
> because tokens have been cleared.{*}{*}
>
> So you can not call *RuntimeInstance.render* on the same AST several times
> which seems to be the intent of this method...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-966) RuntimeInstance.render throws null pointer exception when trying to render the same AST
[
https://issues.apache.org/jira/browse/VELOCITY-966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878147#comment-17878147
]
Dmitry Ponomarev commented on VELOCITY-966:
---
Please see code example:
[https://github.com/techsup69/velocity-966]
It demonstrates multiple usage of parsed template with velocity 1.7 and 2.3.
In velocity 1.7 it works, in 2.3 it fails with NullPointerException.
> RuntimeInstance.render throws null pointer exception when trying to render
> the same AST
>
>
> Key: VELOCITY-966
> URL: https://issues.apache.org/jira/browse/VELOCITY-966
> Project: Velocity
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Alex
>Priority: Major
>
> The objective is to use
> *RuntimeInstance.parse* to get the parsed AST for some template and cache the
> AST.
> Then use *RuntimeInstance.render* multiple times to render the text.
>
> It appears that in version 2.3 {*}RuntimeInstance.{*}{*}render{*} invokes the
> Node.init call and at the end of the rendering clears the parser and tokens.
> On the next attempt to render init fails with the NullPointerException
> because tokens have been cleared.{*}{*}
>
> So you can not call *RuntimeInstance.render* on the same AST several times
> which seems to be the intent of this method...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-967) Allows passing a list of Template instances to Template#merge
[
https://issues.apache.org/jira/browse/VELOCITY-967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876991#comment-17876991
]
Thomas Mortagne commented on VELOCITY-967:
--
bq. Couldn't you use some kind of context chaining?
It's not very clear to me what you have in mind exactly.
> Allows passing a list of Template instances to Template#merge
> -
>
> Key: VELOCITY-967
> URL: https://issues.apache.org/jira/browse/VELOCITY-967
> Project: Velocity
> Issue Type: Improvement
> Components: Engine
>Affects Versions: 2.3
>Reporter: Thomas Mortagne
>Priority: Major
>
> Instead of the list of template names.
> In [XWiki|https://www.xwiki.org] it's possible to define Velocity macros in
> all kind of locations (files, pages, attachment in a page, object fields,
> etc.), they can include each other but more importantly you can have several
> Velocity scripts in the same page (or a page which included several other
> pages and now has several scripts) with one of the scripts reusing macros
> defined in a previous one.
> So far, it was not too much of a problem, I just kept reusing the same
> Template instance:
> {code}
> currentTemplate.setResourceLoader(new SingletonResourceReader(script));
> currentTemplate.process();
> currentTemplate.merge(context, out);
> {code}
> repeat...
> But I'm starting to work on caching compiled Velocity (i.e. {{Template}}
> instances) and execute them later in various different contexts. It's not a
> problem for variables since they are stored in the context, but there is
> still a problem for which I don't have a clean solution: passing current
> macros (gathered from previous executed templates) to the currently executed
> one. I first thought I could just call VelocityContext#setMacroLibraries
> before template.merge(mergeContext, out); but unfortunately, merge "breaks"
> the current context (it replaces the context macro libraries by an empty
> list) and using template.merge(mergeContext, out, names); and a custom
> ResourceManager would add too much complexity for various use cases.
> My current workaround is to pass a custom Velocity context which overwrite
> setMacroLibraries and ignore any call with an empty list as parameters (yeah,
> not a huge fan either).
> The simplest for us would be to pass directly the macro libraries Template
> instances to Template#merge (to be perfectly honest, passing just the macros
> is our real need but passing a Template list is more generic and in line with
> what Template#merge is already doing in practice).
> My plan is to write a (very easy) pull request, but I wanted to discuss the
> idea first to see how well it's received.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [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&focusedCommentId=17876729#comment-17876729
]
Charles Parker edited comment on VELTOOLS-202 at 8/26/24 1:51 PM:
--
I want to voice my support for this issue. The lack of Servlet API 6.0 support
is holding back a lot of projects, and I believe it was in part responsible for
the retirement of Apache Tiles.
I recently ported *velocity-tools-view-3.1* to Servlet API 6.0, and found that
only the following changes were needed:
Change "import javax.servlet." to "import jakarta.servlet." for the following
files/lines:
* org.apache.velocity.tools.view.AbstractSearchTool.java [line 24]
* org.apache.velocity.tools.view.BreadcrumbTool.java [line 28]
* org.apache.velocity.tools.view.BrowserTool.java [line 34]
* org.apache.velocity.tools.view.CookieTool.java [line 24-26]
* org.apache.velocity.tools.view.IncludeTool.java [line 25]
* org.apache.velocity.tools.view.JeeConfig.java [line 23]
* org.apache.velocity.tools.view.JeeContextConfig.java [line 23]
* org.apache.velocity.tools.view.JeeFilterConfig.java [line 23-24]
* org.apache.velocity.tools.view.JeeServletConfig.java [line 23-24]
* org.apache.velocity.tools.view.JsonTool.java [line 22]
* org.apache.velocity.tools.view.LinkTool.java [line 25-26]
* org.apache.velocity.tools.view.LinkTool.java [line 25-26]
* org.apache.velocity.tools.view.ParameterTool.java [line 25]
* org.apache.velocity.tools.view.ServletUtils.java [lines 28-32]
* org.apache.velocity.tools.view.UiDependencyTool.java [lines 29-30]
* org.apache.velocity.tools.view.VelocityLayoutServlet.java [lines 24-27]
* org.apache.velocity.tools.view.VelocityView.java [lines 28-32]
* org.apache.velocity.tools.view.VelocityViewFilter.java [lines 22-29]
* org.apache.velocity.tools.view.VelocityViewServlet.java [lines 27-32]
* org.apache.velocity.tools.view.ViewContext.java [lines 22-24]
* org.apache.velocity.tools.view.ViewContextTool.java [lines 24-26]
* org.apache.velocity.tools.view.ViewImportSupport.java [lines 36-43]
* org.apache.velocity.tools.view.ViewToolContext.java [lines 23-26]
* org.apache.velocity.tools.view.ViewToolManager.java [lines 23-27]
* org.apache.velocity.tools.view.WebappResourceLoader.java [line 28]
* org.apache.velocity.tools.view.WebappUberspector.java [lines 22-24]
* org.apache.velocity.tools.view.XmlTool.java [line 25]
The above lines are simply imports for the following classes:
* javax.servlet.Filter
* javax.servlet.FilterChain
* javax.servlet.FilterConfig
* javax.servlet.ServletRequest
* javax.servlet.RequestDispatcher
* javax.servlet.ServletConfig
* javax.servlet.ServletContext
* javax.servlet.ServletException
* javax.servlet.ServletOutputStream
* javax.servlet.WriteListener
* javax.servlet.http.HttpSession
* javax.servlet.http.HttpServletRequest
* javax.servlet.http.HttpServletResponse
* javax.servlet.http.Cookie
None of the above changes are affected by other API changes in Servlet API 6.0.
This is simply changing the package namespace for imports from "javax" to
"jakarta". I have a clean build of this project that works in Tomcat 10.1, and
I was also able to successfully port Apache Tiles 3 (which relies on this
project) over to Servlet API 6.0. Everything works perfectly.
Instead of creating a separate branch (which is a solution, but not the best,
IMO), I would also like to direct your attention to the approach that Apache
freemarker-2.3.33 took.
The FreeMarker team recently took a "yes, and" approach to support Servlet API
3.0 through Servlet API 6.0 (inclusively) {*}in the same build{*}. They created
an additional jakarta package, and depending on which runtime dependency the
developer uses, they have the option of using the original (javax) package or
the new (jakarta) package. The solution is both backwards and forward
compatible.
See Issue FREEMARKER-218
I believe the approach the FreeMarker team took is a fantastic solution that
cuts through all of the arguments against supporting a modern Servlet API.
I would also like to point out that while the velocity tools project has marked
this issue's priority as "Trivial", the FreeMarker team assigned theirs
priority "Major". I recommend the velocity team bump up the priority of this
issue to "Major" as well.
was (Author: ctparker):
I want to voice my support for this issue. The lack of Servlet API 6.0 support
is holding back a lot of projects, and I believe it was in part responsible for
the retirement of Apache Tiles.
I recently ported *velocity-tools-view-3.1* to Servlet API 6.0, and found that
only the following changes were needed:
Change "import javax.servlet." to "import jakarta.servlet." for the following
files/lines:
* org.apache.velocit
[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&focusedCommentId=17876729#comment-17876729
]
Charles Parker edited comment on VELTOOLS-202 at 8/26/24 1:49 PM:
--
I want to voice my support for this issue. The lack of Servlet API 6.0 support
is holding back a lot of projects, and I believe it was in part responsible for
the retirement of Apache Tiles.
I recently ported *velocity-tools-view-3.1* to Servlet API 6.0, and found that
only the following changes were needed:
Change "import javax.servlet." to "import jakarta.servlet." for the following
files/lines:
* org.apache.velocity.tools.view.AbstractSearchTool.java [line 24]
* org.apache.velocity.tools.view.BreadcrumbTool.java [line 28]
* org.apache.velocity.tools.view.BrowserTool.java [line 34]
* org.apache.velocity.tools.view.CookieTool.java [line 24-26]
* org.apache.velocity.tools.view.IncludeTool.java [line 25]
* org.apache.velocity.tools.view.JeeConfig.java [line 23]
* org.apache.velocity.tools.view.JeeContextConfig.java [line 23]
* org.apache.velocity.tools.view.JeeFilterConfig.java [line 23-24]
* org.apache.velocity.tools.view.JeeServletConfig.java [line 23-24]
* org.apache.velocity.tools.view.JsonTool.java [line 22]
* org.apache.velocity.tools.view.LinkTool.java [line 25-26]
* org.apache.velocity.tools.view.LinkTool.java [line 25-26]
* org.apache.velocity.tools.view.ParameterTool.java [line 25]
* org.apache.velocity.tools.view.ServletUtils.java [lines 28-32]
* org.apache.velocity.tools.view.UiDependencyTool.java [lines 29-30]
* org.apache.velocity.tools.view.VelocityLayoutServlet.java [lines 24-27]
* org.apache.velocity.tools.view.VelocityView.java [lines 28-32]
* org.apache.velocity.tools.view.VelocityViewFilter.java [lines 22-29]
* org.apache.velocity.tools.view.VelocityViewServlet.java [lines 27-32]
* org.apache.velocity.tools.view.ViewContext.java [lines 22-24]
* org.apache.velocity.tools.view.ViewContextTool.java [lines 24-26]
* org.apache.velocity.tools.view.ViewImportSupport.java [lines 36-43]
* org.apache.velocity.tools.view.ViewToolContext.java [lines 23-26]
* org.apache.velocity.tools.view.ViewToolManager.java [lines 23-27]
* org.apache.velocity.tools.view.WebappResourceLoader.java [line 28]
* org.apache.velocity.tools.view.WebappUberspector.java [lines 22-24]
* org.apache.velocity.tools.view.XmlTool.java [line 25]
The above lines are simply imports for the following classes:
* javax.servlet.Filter
* javax.servlet.FilterChain
* javax.servlet.FilterConfig
* javax.servlet.ServletRequest
* javax.servlet.RequestDispatcher
* javax.servlet.ServletConfig
* javax.servlet.ServletContext
* javax.servlet.ServletException
* javax.servlet.ServletOutputStream
* javax.servlet.WriteListener
* javax.servlet.http.HttpSession
* javax.servlet.http.HttpServletRequest
* javax.servlet.http.HttpServletResponse
* javax.servlet.http.Cookie
None of the above changes are affected by other API changes in Servlet API 6.0.
This is simply changing the package namespace for imports from "javax" to
"jakarta". I have a clean build of this project that works in Tomcat 10.1, and
I was also able to successfully port Apache Tiles 3 (which relies on this
project) over to Servlet API 6.0. Everything works perfectly.
Instead of creating a separate branch (which is a solution, but not the best,
IMO), I would also like to direct your attention to the approach that Apache
freemarker-2.3.33 took.
The FreeMarker team recently took a "yes, and" approach to support Servlet API
3.0 through Servlet API 6.0 (inclusively) {*}in the same build{*}. They created
an additional jakarta package, and depending on which runtime dependency the
developer uses, they have the option of using the original (javax) package or
the new (jakarta) package. The solution is both backwards and forward
compatible.
See Issue FREEMARKER-218
I believe the approach the FreeMarker team took is a fantastic solution that
cuts through all of the arguments against supporting a modern Servlet API.
was (Author: ctparker):
I want to voice my support for this issue. The lack of Servlet API 6.0 support
is holding back a lot of projects, and I believe it was in part responsible for
the retirement of Apache Tiles.
I recently ported *velocity-tools-view-3.1* to Servlet API 6.0, and found that
only the following changes were needed:
Change "import javax.servlet." to "import jakarta.servlet." for the following
files/lines:
* org.apache.velocity.tools.view.AbstractSearchTool.java [line 24]
* org.apache.velocity.tools.view.BreadcrumbTool.java [line 28]
* org.apache.velocity.tools.view.BrowserTool.java [line 34]
* org.apache.velocity.tools.view.CookieTool.java [line 24-26]
* org.apache.velocity.tools.view.IncludeToo
[jira] [Commented] (VELTOOLS-202) VelocityViewServlet extending from jakarta.servlet instead of javax.servlet
[
https://issues.apache.org/jira/browse/VELTOOLS-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876729#comment-17876729
]
Charles Parker commented on VELTOOLS-202:
-
I want to voice my support for this issue. The lack of Servlet API 6.0 support
is holding back a lot of projects, and I believe it was in part responsible for
the retirement of Apache Tiles.
I recently ported *velocity-tools-view-3.1* to Servlet API 6.0, and found that
only the following changes were needed:
Change "import javax.servlet." to "import jakarta.servlet." for the following
files/lines:
* org.apache.velocity.tools.view.AbstractSearchTool.java [line 24]
* org.apache.velocity.tools.view.BreadcrumbTool.java [line 28]
* org.apache.velocity.tools.view.BrowserTool.java [line 34]
* org.apache.velocity.tools.view.CookieTool.java [line 24-26]
* org.apache.velocity.tools.view.IncludeTool.java [line 25]
* org.apache.velocity.tools.view.JeeConfig.java [line 23]
* org.apache.velocity.tools.view.JeeContextConfig.java [line 23]
* org.apache.velocity.tools.view.JeeFilterConfig.java [line 23-24]
* org.apache.velocity.tools.view.JeeServletConfig.java [line 23-24]
* org.apache.velocity.tools.view.JsonTool.java [line 22]
* org.apache.velocity.tools.view.LinkTool.java [line 25-26]
* org.apache.velocity.tools.view.LinkTool.java [line 25-26]
* org.apache.velocity.tools.view.ParameterTool.java [line 25]
* org.apache.velocity.tools.view.ServletUtils.java [lines 28-32]
* org.apache.velocity.tools.view.UiDependencyTool.java [lines 29-30]
* org.apache.velocity.tools.view.VelocityLayoutServlet.java [lines 24-27]
* org.apache.velocity.tools.view.VelocityView.java [lines 28-32]
* org.apache.velocity.tools.view.VelocityViewFilter.java [lines 22-29]
* org.apache.velocity.tools.view.VelocityViewServlet.java [lines 27-32]
* org.apache.velocity.tools.view.ViewContext.java [lines 22-24]
* org.apache.velocity.tools.view.ViewContextTool.java [lines 24-26]
* org.apache.velocity.tools.view.ViewImportSupport.java [lines 36-43]
* org.apache.velocity.tools.view.ViewToolContext.java [lines 23-26]
* org.apache.velocity.tools.view.ViewToolManager.java [lines 23-27]
* org.apache.velocity.tools.view.WebappResourceLoader.java [line 28]
* org.apache.velocity.tools.view.WebappUberspector.java [lines 22-24]
* org.apache.velocity.tools.view.XmlTool.java [line 25]
The above lines are simply imports for the following classes:
* javax.servlet.Filter
* javax.servlet.FilterChain
* javax.servlet.FilterConfig
* javax.servlet.ServletRequest
* javax.servlet.RequestDispatcher
* javax.servlet.ServletConfig
* javax.servlet.ServletContext
* javax.servlet.ServletException
* javax.servlet.ServletOutputStream
* javax.servlet.WriteListener
* javax.servlet.http.HttpSession
* javax.servlet.http.HttpServletRequest
* javax.servlet.http.HttpServletResponse
* javax.servlet.http.Cookie
None of the above changes are affected by other API changes in Servlet API 6.0.
This is simply changing the package namespace for imports from "javax" to
"jakarta". I have a clean build of this project that works in Tomcat 10.1, and
I was also able to successfully port Apache Tiles 3 (which relies on this
project) over to Servlet API 6.0. Everything works perfectly.
Instead of creating a separate branch (which is a solution, but not the best,
IMO), I would also like to direct your attention to the approach that Apache
freemarker-2.3.33, which recently took a "yes, and" approach to support Servlet
API 3.0 through Servlet API 6.0 (inclusively) {*}in the same build{*}. That
project created an additional jakarta package, and depending on which runtime
dependency the developer uses, they have the option of using the original
package or the jakarta package. The solution is backwards and forward
compatible.
See Issue FREEMARKER-218 https://issues.apache.org/jira/browse/FREEMARKER-218
I believe the approach the FreeMarker team took is a fantastic solution that
cuts through all of the arguments against supporting a modern Servlet API.
> 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 i
[jira] [Closed] (VELOCITY-952) Velocity is calling the "wrong" method
[
https://issues.apache.org/jira/browse/VELOCITY-952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson closed VELOCITY-952.
---
Fix Version/s: 2.4
Assignee: Claude Brisson
Resolution: Fixed
> Velocity is calling the "wrong" method
> --
>
> Key: VELOCITY-952
> URL: https://issues.apache.org/jira/browse/VELOCITY-952
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Thomas Mortagne
>Assignee: Claude Brisson
>Priority: Major
> Fix For: 2.4
>
>
> OK, the title is maybe a bit harsh, but it catches the eyes :)
> At XWiki we recently started testing on Java 17 to see if there is any
> problem which leaded us to add things like {{--add-opens
> java.base/java.util=ALL-UNNAMED}} but Velocity happen to be the source of
> another problem related to the new module world.
> When doing something like {{$datetool.timeZone.getOffset(0)}} ($datetool
> being the org.apache.velocity.tools.generic.DateTool) we get the following
> error:
> {noformat}
> ...
> Caused by: java.lang.IllegalAccessException: class
> org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl cannot
> access class sun.util.calendar.ZoneInfo (in module java.base) because module
> java.base does not export sun.util.calendar to unnamed module @7ca16adc
> at
> java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:392)
> at
> java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674)
> at java.base/java.lang.refledact.Method.invoke(Method.java:560)
> at
> org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:571)
> at
> org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:554)
> at
> org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:221)
> ... 199 more
> {noformat}
> The reason is that while the developer intent/expectation was to call
> "java.util.TimeZone#getOffset(0)" what Velocity really called from JVM point
> of view is "sun.util.calendar.ZoneInfo.getOffset(0)" directly.
> That's because Velocity is doing (I assume, since I did not check the exact
> code) the equivalent of:
> {noformat}
> java.util.TimeZone.getDefault().getClass().getMethod("getOffset",
> long.class).invoke(TimeZone.getDefault(), 0);
> {noformat}
> which is itself the equivalent of:
> {noformat}
> sun.util.calendar.ZoneInfo.class.getMethod("getOffset",
> long.class).invoke(TimeZone.getDefault(), 0);
> {noformat}
> I guess the only way to fix this would be to track down the lowest overridden
> Method (I agree, it might not always be easy to choose between two interfaces
> declaring a method with the same signature, but choosing the first one we
> find from the same hierarchy level is still better than nothing) and call
> that one instead. With the use case used as example in this issue, that would
> mean ending up doing the equivalent of:
> {noformat}
> java.util.TimeZone.class.getMethod("getOffset",
> long.class).invoke(TimeZone.getDefault(), 0);
> {noformat}
> which, from JVM point of view, is covered by the {{--add-opens
> java.base/java.util=ALL-UNNAMED}}.
> It would be a big change, but at least can't think of any retro-compatibility
> problem it might cause.
> One might be tempted to answer "just add {{--add-opens
> java.base/sun.util.calendar=ALL-UNNAMED}}" but it does not seem fair as this
> is not what the API that the script uses was exposing at all, you might need
> to document a different one for each JVM implementation (even if it's
> probably unlikely for this specific example) but more importantly you will
> potentially need quite a lot of those and will only discover it at runtime
> since it's not so easy to guess from an API in which you only know the public
> JVM classes since that's what you manipulate.
> I would be happy to work on this, but I wanted first ask what others think
> about this problem in general and the possible solutions I may have missed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-952) Velocity is calling the "wrong" method
[
https://issues.apache.org/jira/browse/VELOCITY-952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876636#comment-17876636
]
Claude Brisson commented on VELOCITY-952:
-
The fix in ready for review [in this
PR|https://github.com/apache/velocity-engine/pull/50].
> Velocity is calling the "wrong" method
> --
>
> Key: VELOCITY-952
> URL: https://issues.apache.org/jira/browse/VELOCITY-952
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Thomas Mortagne
>Priority: Major
>
> OK, the title is maybe a bit harsh, but it catches the eyes :)
> At XWiki we recently started testing on Java 17 to see if there is any
> problem which leaded us to add things like {{--add-opens
> java.base/java.util=ALL-UNNAMED}} but Velocity happen to be the source of
> another problem related to the new module world.
> When doing something like {{$datetool.timeZone.getOffset(0)}} ($datetool
> being the org.apache.velocity.tools.generic.DateTool) we get the following
> error:
> {noformat}
> ...
> Caused by: java.lang.IllegalAccessException: class
> org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl cannot
> access class sun.util.calendar.ZoneInfo (in module java.base) because module
> java.base does not export sun.util.calendar to unnamed module @7ca16adc
> at
> java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:392)
> at
> java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674)
> at java.base/java.lang.refledact.Method.invoke(Method.java:560)
> at
> org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:571)
> at
> org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:554)
> at
> org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:221)
> ... 199 more
> {noformat}
> The reason is that while the developer intent/expectation was to call
> "java.util.TimeZone#getOffset(0)" what Velocity really called from JVM point
> of view is "sun.util.calendar.ZoneInfo.getOffset(0)" directly.
> That's because Velocity is doing (I assume, since I did not check the exact
> code) the equivalent of:
> {noformat}
> java.util.TimeZone.getDefault().getClass().getMethod("getOffset",
> long.class).invoke(TimeZone.getDefault(), 0);
> {noformat}
> which is itself the equivalent of:
> {noformat}
> sun.util.calendar.ZoneInfo.class.getMethod("getOffset",
> long.class).invoke(TimeZone.getDefault(), 0);
> {noformat}
> I guess the only way to fix this would be to track down the lowest overridden
> Method (I agree, it might not always be easy to choose between two interfaces
> declaring a method with the same signature, but choosing the first one we
> find from the same hierarchy level is still better than nothing) and call
> that one instead. With the use case used as example in this issue, that would
> mean ending up doing the equivalent of:
> {noformat}
> java.util.TimeZone.class.getMethod("getOffset",
> long.class).invoke(TimeZone.getDefault(), 0);
> {noformat}
> which, from JVM point of view, is covered by the {{--add-opens
> java.base/java.util=ALL-UNNAMED}}.
> It would be a big change, but at least can't think of any retro-compatibility
> problem it might cause.
> One might be tempted to answer "just add {{--add-opens
> java.base/sun.util.calendar=ALL-UNNAMED}}" but it does not seem fair as this
> is not what the API that the script uses was exposing at all, you might need
> to document a different one for each JVM implementation (even if it's
> probably unlikely for this specific example) but more importantly you will
> potentially need quite a lot of those and will only discover it at runtime
> since it's not so easy to guess from an API in which you only know the public
> JVM classes since that's what you manipulate.
> I would be happy to work on this, but I wanted first ask what others think
> about this problem in general and the possible solutions I may have missed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-952) Velocity is calling the "wrong" method
[
https://issues.apache.org/jira/browse/VELOCITY-952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson updated VELOCITY-952:
Description:
OK, the title is maybe a bit harsh, but it catches the eyes :)
At XWiki we recently started testing on Java 17 to see if there is any problem
which leaded us to add things like {{--add-opens
java.base/java.util=ALL-UNNAMED}} but Velocity happen to be the source of
another problem related to the new module world.
When doing something like {{$datetool.timeZone.getOffset(0)}} ($datetool being
the org.apache.velocity.tools.generic.DateTool) we get the following error:
{noformat}
...
Caused by: java.lang.IllegalAccessException: class
org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl cannot
access class sun.util.calendar.ZoneInfo (in module java.base) because module
java.base does not export sun.util.calendar to unnamed module @7ca16adc
at
java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:392)
at
java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674)
at java.base/java.lang.refledact.Method.invoke(Method.java:560)
at
org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:571)
at
org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:554)
at
org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:221)
... 199 more
{noformat}
The reason is that while the developer intent/expectation was to call
"java.util.TimeZone#getOffset(0)" what Velocity really called from JVM point of
view is "sun.util.calendar.ZoneInfo.getOffset(0)" directly.
That's because Velocity is doing (I assume, since I did not check the exact
code) the equivalent of:
{noformat}
java.util.TimeZone.getDefault().getClass().getMethod("getOffset",
long.class).invoke(TimeZone.getDefault(), 0);
{noformat}
which is itself the equivalent of:
{noformat}
sun.util.calendar.ZoneInfo.class.getMethod("getOffset",
long.class).invoke(TimeZone.getDefault(), 0);
{noformat}
I guess the only way to fix this would be to track down the lowest overridden
Method (I agree, it might not always be easy to choose between two interfaces
declaring a method with the same signature, but choosing the first one we find
from the same hierarchy level is still better than nothing) and call that one
instead. With the use case used as example in this issue, that would mean
ending up doing the equivalent of:
{noformat}
java.util.TimeZone.class.getMethod("getOffset",
long.class).invoke(TimeZone.getDefault(), 0);
{noformat}
which, from JVM point of view, is covered by the {{--add-opens
java.base/java.util=ALL-UNNAMED}}.
It would be a big change, but at least can't think of any retro-compatibility
problem it might cause.
One might be tempted to answer "just add {{--add-opens
java.base/sun.util.calendar=ALL-UNNAMED}}" but it does not seem fair as this is
not what the API that the script uses was exposing at all, you might need to
document a different one for each JVM implementation (even if it's probably
unlikely for this specific example) but more importantly you will potentially
need quite a lot of those and will only discover it at runtime since it's not
so easy to guess from an API in which you only know the public JVM classes
since that's what you manipulate.
I would be happy to work on this, but I wanted first ask what others think
about this problem in general and the possible solutions I may have missed.
was:
OK, the title is maybe a bit harsh, but it catches the eyes :)
At XWiki we recently started testing on Java 17 to see if there is any problem
which leaded us to add things like {{--add-opens
java.base/java.util=ALL-UNNAMED}} but Velocity happen to be the source of
another problem related to the new module world.
When doing something like {{$datetool.timeZone.getOffset(0)}} ($datetool being
the org.apache.velocity.tools.generic.DateTool) we get the following error:
{noformat}
...
Caused by: java.lang.IllegalAccessException: class
org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl cannot
access class sun.util.calendar.ZoneInfo (in module java.base) because module
java.base does not export sun.util.calendar to unnamed module @7ca16adc
at
java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:392)
at
java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674)
at java.base/java.lang.reflect.Method.invoke(Method.java:560)
at
org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:571)
at
org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:554)
at
org.apache.velocity.runtime.parser.node.AST
[jira] [Closed] (VELOCITY-979) Performance issue with comparing strings in Velocity
[
https://issues.apache.org/jira/browse/VELOCITY-979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson closed VELOCITY-979.
---
Fix Version/s: 2.4
Resolution: Fixed
Should have been fixed by commit e86a2fbf
> Performance issue with comparing strings in Velocity
>
>
> Key: VELOCITY-979
> URL: https://issues.apache.org/jira/browse/VELOCITY-979
> Project: Velocity
> Issue Type: Improvement
> Components: Engine
>Affects Versions: 2.3
>Reporter: Alex
>Priority: Major
> Fix For: 2.4
>
>
> Most Velocity compare expressions eventually use ASTComparisonNode which at
> first attempts to treat data types as numbers:
>
> Boolean result = compareNumbers(left, right);
> if (result == null)
> {
> result = compareNonNumber(left, right);
> }
>
> There is fairly large overhead when attempting to create BigDecimal from
> non-numeric strings used in comparison in the DuckType.asNumber:
>
> if (coerceType)
> {
> String string = asString(value);// coerce to string
> if (string != null)
> {
> return new BigDecimal(string);
> }
> }
>
> The exception is created capturing stack, etc. On large volume of compare
> operations it's very visible.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Closed] (VELOCITY-957) Unexpected compare result
[
https://issues.apache.org/jira/browse/VELOCITY-957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson closed VELOCITY-957.
---
Fix Version/s: 2.4
Assignee: Claude Brisson
Resolution: Fixed
Fixed by commit e86a2fbf
> Unexpected compare result
> -
>
> Key: VELOCITY-957
> URL: https://issues.apache.org/jira/browse/VELOCITY-957
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Kai Bächle
>Assignee: Claude Brisson
>Priority: Major
> Fix For: 2.4
>
>
> {code:java}
> #if('1' == '1.0')same#{else}different#end {code}
> has "same" as result using velocity 2.3 and "different" using 1.7
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Closed] (VELOCITY-944) Macros in string literals are not resolved when local_scope is enabled
[
https://issues.apache.org/jira/browse/VELOCITY-944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson closed VELOCITY-944.
---
Assignee: Claude Brisson
Resolution: Cannot Reproduce
I could not reproduce the problem in any of the 2.x versions. Please reopen
with a complete test case.
> Macros in string literals are not resolved when local_scope is enabled
> --
>
> Key: VELOCITY-944
> URL: https://issues.apache.org/jira/browse/VELOCITY-944
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.0, 2.1, 2.2, 2.3
>Reporter: Jakub Isakow
>Assignee: Claude Brisson
>Priority: Critical
>
> When local scope is enabled with
> {noformat}
> velocimacro.inline.local_scope=true
> {noformat}
> a template that is using a macro in string literal is not working correctly.
> Example template:
> {code}
> #macro( m $v )
> $v
> #end
> #set($v = "#m('bar')")
> $v
> #m( 'foo' )
> {code}
> Actual result:
> {code}
> #m('bar')
> foo
> {code}
> Expected result:
> {code}
> bar
> foo
> {code}
> The example template is working correctly for velocity 1.7.
> After debugging a bit I think the problem might be caused by creating a new
> Template instance in
> [org.apache.velocity.runtime.parser.node.ASTStringLiteral#init|https://github.com/apache/velocity-engine/blob/2.3/velocity-engine-core/src/main/java/org/apache/velocity/runtime/parser/node/ASTStringLiteral.java#L145-L149].
> Because of that, when macro is being resolved, there is no macro instance
> available in local scope (template instance) and it is rendered as string.
> Locally I was able to make it work by using {{this.template}} when
> {{context.getCurrentResource()}} returns {{null}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Closed] (VELOCITY-975) Unicode characters cause issues
[
https://issues.apache.org/jira/browse/VELOCITY-975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson closed VELOCITY-975.
---
Resolution: Incomplete
> Unicode characters cause issues
> ---
>
> Key: VELOCITY-975
> URL: https://issues.apache.org/jira/browse/VELOCITY-975
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Alex O'Ree
>Priority: Major
>
> Ran across some cases of processing files using velocity with some unicode
> characters in it that caused some unexpected results. Is there anything that
> I can do to prevent or mitigate this short of stripping out a set of bad
> characters before i had the script off to velocity?
>
> {noformat}
> org.apache.velocity.exception.ParseErrorException: Lexical error,
> Encountered: "\u00a0" (160), after : "" at *unset*[line 1, column 19]
> at
> org.apache.velocity.runtime.RuntimeInstance.evaluate(RuntimeInstance.java:1437)
> at
> org.apache.velocity.app.VelocityEngine.evaluate(VelocityEngine.java:239)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-975) Unicode characters cause issues
[
https://issues.apache.org/jira/browse/VELOCITY-975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876494#comment-17876494
]
Claude Brisson commented on VELOCITY-975:
-
The only thing related I could think of is the non-breakable space hack in the
velocity character stream which means "next character is an EOF". But it does
use "\u001C", which does not seem related.
Otherwise, we would need an example of the faulty template section to
understand what's happening.
> Unicode characters cause issues
> ---
>
> Key: VELOCITY-975
> URL: https://issues.apache.org/jira/browse/VELOCITY-975
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Alex O'Ree
>Priority: Major
>
> Ran across some cases of processing files using velocity with some unicode
> characters in it that caused some unexpected results. Is there anything that
> I can do to prevent or mitigate this short of stripping out a set of bad
> characters before i had the script off to velocity?
>
> {noformat}
> org.apache.velocity.exception.ParseErrorException: Lexical error,
> Encountered: "\u00a0" (160), after : "" at *unset*[line 1, column 19]
> at
> org.apache.velocity.runtime.RuntimeInstance.evaluate(RuntimeInstance.java:1437)
> at
> org.apache.velocity.app.VelocityEngine.evaluate(VelocityEngine.java:239)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-967) Allows passing a list of Template instances to Template#merge
[
https://issues.apache.org/jira/browse/VELOCITY-967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876469#comment-17876469
]
Claude Brisson commented on VELOCITY-967:
-
Couldn't you use some kind of context chaining?
> Allows passing a list of Template instances to Template#merge
> -
>
> Key: VELOCITY-967
> URL: https://issues.apache.org/jira/browse/VELOCITY-967
> Project: Velocity
> Issue Type: Improvement
> Components: Engine
>Affects Versions: 2.3
>Reporter: Thomas Mortagne
>Priority: Major
>
> Instead of the list of template names.
> In [XWiki|https://www.xwiki.org] it's possible to define Velocity macros in
> all kind of locations (files, pages, attachment in a page, object fields,
> etc.), they can include each other but more importantly you can have several
> Velocity scripts in the same page (or a page which included several other
> pages and now has several scripts) with one of the scripts reusing macros
> defined in a previous one.
> So far, it was not too much of a problem, I just kept reusing the same
> Template instance:
> {code}
> currentTemplate.setResourceLoader(new SingletonResourceReader(script));
> currentTemplate.process();
> currentTemplate.merge(context, out);
> {code}
> repeat...
> But I'm starting to work on caching compiled Velocity (i.e. {{Template}}
> instances) and execute them later in various different contexts. It's not a
> problem for variables since they are stored in the context, but there is
> still a problem for which I don't have a clean solution: passing current
> macros (gathered from previous executed templates) to the currently executed
> one. I first thought I could just call VelocityContext#setMacroLibraries
> before template.merge(mergeContext, out); but unfortunately, merge "breaks"
> the current context (it replaces the context macro libraries by an empty
> list) and using template.merge(mergeContext, out, names); and a custom
> ResourceManager would add too much complexity for various use cases.
> My current workaround is to pass a custom Velocity context which overwrite
> setMacroLibraries and ignore any call with an empty list as parameters (yeah,
> not a huge fan either).
> The simplest for us would be to pass directly the macro libraries Template
> instances to Template#merge (to be perfectly honest, passing just the macros
> is our real need but passing a Template list is more generic and in line with
> what Template#merge is already doing in practice).
> My plan is to write a (very easy) pull request, but I wanted to discuss the
> idea first to see how well it's received.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Closed] (VELOCITY-966) RuntimeInstance.render throws null pointer exception when trying to render the same AST
[
https://issues.apache.org/jira/browse/VELOCITY-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson closed VELOCITY-966.
---
Resolution: Invalid
> RuntimeInstance.render throws null pointer exception when trying to render
> the same AST
>
>
> Key: VELOCITY-966
> URL: https://issues.apache.org/jira/browse/VELOCITY-966
> Project: Velocity
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Alex
>Priority: Major
>
> The objective is to use
> *RuntimeInstance.parse* to get the parsed AST for some template and cache the
> AST.
> Then use *RuntimeInstance.render* multiple times to render the text.
>
> It appears that in version 2.3 {*}RuntimeInstance.{*}{*}render{*} invokes the
> Node.init call and at the end of the rendering clears the parser and tokens.
> On the next attempt to render init fails with the NullPointerException
> because tokens have been cleared.{*}{*}
>
> So you can not call *RuntimeInstance.render* on the same AST several times
> which seems to be the intent of this method...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Reopened] (VELOCITY-966) RuntimeInstance.render throws null pointer exception when trying to render the same AST
[
https://issues.apache.org/jira/browse/VELOCITY-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson reopened VELOCITY-966:
-
> RuntimeInstance.render throws null pointer exception when trying to render
> the same AST
>
>
> Key: VELOCITY-966
> URL: https://issues.apache.org/jira/browse/VELOCITY-966
> Project: Velocity
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Alex
>Priority: Major
>
> The objective is to use
> *RuntimeInstance.parse* to get the parsed AST for some template and cache the
> AST.
> Then use *RuntimeInstance.render* multiple times to render the text.
>
> It appears that in version 2.3 {*}RuntimeInstance.{*}{*}render{*} invokes the
> Node.init call and at the end of the rendering clears the parser and tokens.
> On the next attempt to render init fails with the NullPointerException
> because tokens have been cleared.{*}{*}
>
> So you can not call *RuntimeInstance.render* on the same AST several times
> which seems to be the intent of this method...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Closed] (VELOCITY-966) RuntimeInstance.render throws null pointer exception when trying to render the same AST
[
https://issues.apache.org/jira/browse/VELOCITY-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson closed VELOCITY-966.
---
Resolution: Fixed
Since Velocity does support template caching, it does obviously support
rendering several times the same AST.
We would need more details or some example code.
I'm closing the issue for now, but feel free to reopen it if you provide new
materials.
> RuntimeInstance.render throws null pointer exception when trying to render
> the same AST
>
>
> Key: VELOCITY-966
> URL: https://issues.apache.org/jira/browse/VELOCITY-966
> Project: Velocity
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Alex
>Priority: Major
>
> The objective is to use
> *RuntimeInstance.parse* to get the parsed AST for some template and cache the
> AST.
> Then use *RuntimeInstance.render* multiple times to render the text.
>
> It appears that in version 2.3 {*}RuntimeInstance.{*}{*}render{*} invokes the
> Node.init call and at the end of the rendering clears the parser and tokens.
> On the next attempt to render init fails with the NullPointerException
> because tokens have been cleared.{*}{*}
>
> So you can not call *RuntimeInstance.render* on the same AST several times
> which seems to be the intent of this method...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-965) Velocity 1.7 vs velocity 2.3: Getting thread synchronization issue
[
https://issues.apache.org/jira/browse/VELOCITY-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876466#comment-17876466
]
Claude Brisson commented on VELOCITY-965:
-
[This PR|https://github.com/apache/velocity-engine/pull/49] fixes thread safety
by means of prepared statements pooling.
> Velocity 1.7 vs velocity 2.3: Getting thread synchronization issue
> --
>
> Key: VELOCITY-965
> URL: https://issues.apache.org/jira/browse/VELOCITY-965
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Amrit
>Priority: Major
>
> Recently we migrated from Velocity 1.7 to Velocity 2.3. We see the below
> error intermittently which is a possible thread synchronization issue with
> Velocity Engine. The resultset is getting closed while another thread is
> making use of it.
> {noformat}
> 2023-04-15 10:36:33.472 ERROR [org.apache.velocity.loader.ds]
> {344} - DataSourceResourceLoader: database problem while getting timestamp of
> 'xyz_abc':
> java.sql.SQLException: Closed Resultset: next
> at
> oracle.jdbc.driver.InsensitiveScrollableResultSet.ensureOpen(InsensitiveScrollableResultSet.java:109)
> ~[ojdbc8.jar:12.2.0.1.0]
> at
> oracle.jdbc.driver.InsensitiveScrollableResultSet.next(InsensitiveScrollableResultSet.java:398)
> ~[ojdbc8.jar:12.2.0.1.0]
> at
> weblogic.jdbc.wrapper.ResultSet_oracle_jdbc_driver_ForwardOnlyResultSet.next(Unknown
> Source) ~[CodeGenerator.class:12.2.1.3]
> at
> org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader.readLastModified(DataSourceResourceLoader.java:326)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader.getLastModified(DataSourceResourceLoader.java:240)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:446)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:346)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1677)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1656)
> ~[velocity-engine-core-2.3.jar:2.3]
> at
> org.apache.velocity.app.VelocityEngine.getTemplate(VelocityEngine.java:314)
> ~[velocity-engine-core-2.3.jar:2.3]
> {noformat}
> Reference:
> https://stackoverflow.com/questions/2794167/is-resultset-thread-safe
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Closed] (VELOCITY-982) Velocity 2.x - Velocity.properties - Additional introspector.restrict.classes
[ https://issues.apache.org/jira/browse/VELOCITY-982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson closed VELOCITY-982. --- Fix Version/s: 2.4 Assignee: Claude Brisson Resolution: Fixed Requested restrictions have been added by commit 2c15764e > Velocity 2.x - Velocity.properties - Additional introspector.restrict.classes > - > > Key: VELOCITY-982 > URL: https://issues.apache.org/jira/browse/VELOCITY-982 > Project: Velocity > Issue Type: Improvement > Components: Build >Affects Versions: 2.0, 2.1, 2.2, 2.3, 2.4.2 >Reporter: John Tal >Assignee: Claude Brisson >Priority: Major > Fix For: 2.4 > > > In Velocity.properties, the introspector.restrict.classes entries. > I assume additions to this file in that section resolved for CVE-2020-13936 > (templating can interact with the system)? Please confirm what commits or > classes, settings did indeed resolve CVE-2020-13936. We really need to know > because we are stuck on 1.7 and need to fork/patch. > Along these lines of further security hardening, aren't there more entries > needed in the introspect.restrict.classes section such as: > java.lang.ProcessBuilder > java.lang.Reflect > javax.management.MBeanServer > java.net.Socket > javax.script.ScriptEngine > > Finally, please confirm whether Velocity is largely in CVE patch mode only > and is not really an active project given that there is much more talk today > about Apache FreeMarker. Just trying to determine the level of support and > engagement from the Apache Velocity maintainers. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Resolved] (VELOCITY-969) Lower scripts parser performance after update from 1.6 to 2.3 velocity version
[ https://issues.apache.org/jira/browse/VELOCITY-969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson resolved VELOCITY-969. - Resolution: Duplicate If the performance issue is still here once VELOCITY-979 is fixed, feel free to reopen this issue. > Lower scripts parser performance after update from 1.6 to 2.3 velocity version > -- > > Key: VELOCITY-969 > URL: https://issues.apache.org/jira/browse/VELOCITY-969 > Project: Velocity > Issue Type: Bug >Reporter: Magdalena Karpierz >Priority: Critical > Attachments: SampleScript.zip > > > Hello Team, > > We have problems after update velocity 1.6.3 to 2.3 version with parsing > performance of the scripts which include many macros inside and overall > lenght of the script is about 3000 lines. > Performance execution of this kind of scripts decreased 10 times, example > script execution in velocity1 took: 1sec. and in velocity2: 6 to 10 seconds. > > Did You observe such performance issues? > Can You suggest us a potential solution for this problem? > > I prioritized this ticket as a critical, because our customers saw this > immediately and it blocks some further activities. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Closed] (VELOCITY-953) VelocimacroProxy polutes context stack due to wrong handling of #break and exceptions
[
https://issues.apache.org/jira/browse/VELOCITY-953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson closed VELOCITY-953.
---
Resolution: Fixed
PR has been merged
> VelocimacroProxy polutes context stack due to wrong handling of #break and
> exceptions
> -
>
> Key: VELOCITY-953
> URL: https://issues.apache.org/jira/browse/VELOCITY-953
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Janek Schumann
>Priority: Major
>
> The render method of org.apache.velocity.runtime.directive.VelocimacroProxy
> contains the following code:
> {code:java}
> try
> {
> // render the velocity macro
> context.pushCurrentMacroName(macroName);
> nodeTree.render(context, writer);
> context.popCurrentMacroName();
> return true;
> }{code}
> Everytime, a VM is exited via #break - or any other exception for that matter
> - the context stack isn't cleaned up properly.
> {{This will lead to a fatal error fast because the max call depth is reached
> quite soon. Even with a max call depth of 200 or more this will happen,
> depending on the complexity of the template and the usage of #break etc.}}
> *{{Proposed solution}}*
> {{Similar to #parse, move the popCurrentMacroName to finally like so}}
> {code:java}
> finally
> {
> // if MacroOverflowException was thrown then it already empties the stack
> // for everything else - e.g. other exceptions - we clean up after ourself
> if (context.getCurrentMacroCallDepth() > 0)
> context.popCurrentMacroName();
> [...]
> }{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Closed] (VELOCITY-962) Unclosed #[[ is no longer an error
[
https://issues.apache.org/jira/browse/VELOCITY-962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson closed VELOCITY-962.
---
Resolution: Fixed
> Unclosed #[[ is no longer an error
> --
>
> Key: VELOCITY-962
> URL: https://issues.apache.org/jira/browse/VELOCITY-962
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Éamonn McManus
>Priority: Minor
> Fix For: 2.4
>
>
> With Velocity 1.7, if you had {{#[[ without ]]#}} then you would get an
> exception like this:
> {noformat}
> org.apache.velocity.runtime.parser.ParseException: Lexical error:
> org.apache.velocity.runtime.parser.TokenMgrError: Lexical error at line 4,
> column 5. Encountered: after : ""
> at org.apache.velocity.runtime.parser.Parser.parse(Parser.java:136)
> at
> org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:1226)
> at
> org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:1181){noformat}
> However, with 2.3 this is just silently accepted. I think it would be better
> to continue to throw an exception, and better still if the exception message
> indicated where the {{#[[}} started.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-962) Unclosed #[[ is no longer an error
[
https://issues.apache.org/jira/browse/VELOCITY-962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876416#comment-17876416
]
Claude Brisson commented on VELOCITY-962:
-
Fixed by commit b422860c
> Unclosed #[[ is no longer an error
> --
>
> Key: VELOCITY-962
> URL: https://issues.apache.org/jira/browse/VELOCITY-962
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Éamonn McManus
>Priority: Minor
> Fix For: 2.4
>
>
> With Velocity 1.7, if you had {{#[[ without ]]#}} then you would get an
> exception like this:
> {noformat}
> org.apache.velocity.runtime.parser.ParseException: Lexical error:
> org.apache.velocity.runtime.parser.TokenMgrError: Lexical error at line 4,
> column 5. Encountered: after : ""
> at org.apache.velocity.runtime.parser.Parser.parse(Parser.java:136)
> at
> org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:1226)
> at
> org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:1181){noformat}
> However, with 2.3 this is just silently accepted. I think it would be better
> to continue to throw an exception, and better still if the exception message
> indicated where the {{#[[}} started.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-962) Unclosed #[[ is no longer an error
[
https://issues.apache.org/jira/browse/VELOCITY-962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson updated VELOCITY-962:
Fix Version/s: 2.4
> Unclosed #[[ is no longer an error
> --
>
> Key: VELOCITY-962
> URL: https://issues.apache.org/jira/browse/VELOCITY-962
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Éamonn McManus
>Priority: Minor
> Fix For: 2.4
>
>
> With Velocity 1.7, if you had {{#[[ without ]]#}} then you would get an
> exception like this:
> {noformat}
> org.apache.velocity.runtime.parser.ParseException: Lexical error:
> org.apache.velocity.runtime.parser.TokenMgrError: Lexical error at line 4,
> column 5. Encountered: after : ""
> at org.apache.velocity.runtime.parser.Parser.parse(Parser.java:136)
> at
> org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:1226)
> at
> org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:1181){noformat}
> However, with 2.3 this is just silently accepted. I think it would be better
> to continue to throw an exception, and better still if the exception message
> indicated where the {{#[[}} started.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELTOOLS-210) velocity 1.7 vs velocity 2.3 : the evaluation of if condition in script is different
[
https://issues.apache.org/jira/browse/VELTOOLS-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson updated VELTOOLS-210:
Component/s: VelocityView
> velocity 1.7 vs velocity 2.3 : the evaluation of if condition in script is
> different
> -
>
> Key: VELTOOLS-210
> URL: https://issues.apache.org/jira/browse/VELTOOLS-210
> Project: Velocity Tools
> Issue Type: Bug
> Components: VelocityView
>Affects Versions: 3.1
>Reporter: ambika
>Priority: Major
>
> *script used :*
>
> Map variables = new HashMap<>();
> variables.put("key1", "value");
>
> Context context = velocityEngine.getToolsContext(variables);
>
> String inString = "#set($value = \"key value false\")" +
> "#if(${key1} == 1 ||\"yes\" )" +
> " #set($value = \"{*}{{*}}key value true{{*}}{*}\")" +
> "#end\n${value}";
>
> inString = velocityEngine.evaluate(context, "tag", inString);
> System.out.println(inString);
>
>
> Output:
>
> older version output : key value true
>
> newer version output : key value false
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Moved] (VELTOOLS-210) velocity 1.7 vs velocity 2.3 : the evaluation of if condition in script is different
[
https://issues.apache.org/jira/browse/VELTOOLS-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson moved VELOCITY-955 to VELTOOLS-210:
--
Key: VELTOOLS-210 (was: VELOCITY-955)
Affects Version/s: 3.1
(was: 2.3)
Project: Velocity Tools (was: Velocity)
> velocity 1.7 vs velocity 2.3 : the evaluation of if condition in script is
> different
> -
>
> Key: VELTOOLS-210
> URL: https://issues.apache.org/jira/browse/VELTOOLS-210
> Project: Velocity Tools
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: ambika
>Priority: Major
>
> *script used :*
>
> Map variables = new HashMap<>();
> variables.put("key1", "value");
>
> Context context = velocityEngine.getToolsContext(variables);
>
> String inString = "#set($value = \"key value false\")" +
> "#if(${key1} == 1 ||\"yes\" )" +
> " #set($value = \"{*}{{*}}key value true{{*}}{*}\")" +
> "#end\n${value}";
>
> inString = velocityEngine.evaluate(context, "tag", inString);
> System.out.println(inString);
>
>
> Output:
>
> older version output : key value true
>
> newer version output : key value false
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELTOOLS-209) velocity 1.7 vs velocity 2.3: evaluation of scripts with empty value is not backward compatible
[
https://issues.apache.org/jira/browse/VELTOOLS-209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson updated VELTOOLS-209:
Component/s: GenericTools
> velocity 1.7 vs velocity 2.3: evaluation of scripts with empty value is not
> backward compatible
> ---
>
> Key: VELTOOLS-209
> URL: https://issues.apache.org/jira/browse/VELTOOLS-209
> Project: Velocity Tools
> Issue Type: Bug
> Components: GenericTools
>Affects Versions: 2.0, 3.1
>Reporter: ambika
>Priority: Major
>
> {*}Script{*}:
>
> "vLATE_GATE_IN_6":"#set( $inTimeZone =
> $date.getTimeZone().getTimeZone('Europe/Berlin') )\n\n#set( $outTimeZone =
> $date.getTimeZone().getTimeZone('Asia/Shanghai') )\n\n#set( $locale =
> $date.getLocale() )\n\n#set( $myDate =
> $convert.parseDate(${*}{lead.lateGateIn}{*},\"-MM-dd
> HH:mm\",$locale,$inTimeZone) )\n\n${date.format('-MM-dd hh:mm
> a',$myDate,$locale,$outTimeZone)} "
> {*}note{*}: lead.lateGateIn = "" in the values
> there are multiple other scripts vLATE_GATE_IN_5, vLATE_GATE_IN_4 but in the
> script vLATE_GATE_IN_4 , the values for convert.parseDate is given as below:
> $convert.parseDate("2022-04-22")
>
> {*}Issue{*}:
> Older version of velocity evaluates the script vLATE_GATE_IN_6 to:
> |Time):\\n\\n\\n\\n\\n2022-04-22 11:00 AM|
>
> Newer version of velocity evaluates the script vLATE_GATE_IN_6 to:
> | |Time):\\n\\n\\n\\n\\n${date.format('-MM-dd hh:mm
> a',$myDate,$locale,$outTimeZone)}| |
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-955) velocity 1.7 vs velocity 2.3 : the evaluation of if condition in script is different
[
https://issues.apache.org/jira/browse/VELOCITY-955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876414#comment-17876414
]
Claude Brisson commented on VELOCITY-955:
-
You don't give the definition of the getToolscontext() method. I imagine that
you are using velocity-tools, but we need more details.
The issue is probably linked to the
org.apache.velocity.tools.userCanOverwriteTools web integration configuration
parameter, see [tool's related configuration
doc|https://velocity.apache.org/tools/3.1/frameworks.html].
> velocity 1.7 vs velocity 2.3 : the evaluation of if condition in script is
> different
> -
>
> Key: VELOCITY-955
> URL: https://issues.apache.org/jira/browse/VELOCITY-955
> Project: Velocity
> Issue Type: Bug
> Components: Scripting
>Affects Versions: 2.3
>Reporter: ambika
>Priority: Major
>
> *script used :*
>
> Map variables = new HashMap<>();
> variables.put("key1", "value");
>
> Context context = velocityEngine.getToolsContext(variables);
>
> String inString = "#set($value = \"key value false\")" +
> "#if(${key1} == 1 ||\"yes\" )" +
> " #set($value = \"{*}{{*}}key value true{{*}}{*}\")" +
> "#end\n${value}";
>
> inString = velocityEngine.evaluate(context, "tag", inString);
> System.out.println(inString);
>
>
> Output:
>
> older version output : key value true
>
> newer version output : key value false
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-955) velocity 1.7 vs velocity 2.3 : the evaluation of if condition in script is different
[
https://issues.apache.org/jira/browse/VELOCITY-955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson updated VELOCITY-955:
Component/s: (was: Scripting)
> velocity 1.7 vs velocity 2.3 : the evaluation of if condition in script is
> different
> -
>
> Key: VELOCITY-955
> URL: https://issues.apache.org/jira/browse/VELOCITY-955
> Project: Velocity
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: ambika
>Priority: Major
>
> *script used :*
>
> Map variables = new HashMap<>();
> variables.put("key1", "value");
>
> Context context = velocityEngine.getToolsContext(variables);
>
> String inString = "#set($value = \"key value false\")" +
> "#if(${key1} == 1 ||\"yes\" )" +
> " #set($value = \"{*}{{*}}key value true{{*}}{*}\")" +
> "#end\n${value}";
>
> inString = velocityEngine.evaluate(context, "tag", inString);
> System.out.println(inString);
>
>
> Output:
>
> older version output : key value true
>
> newer version output : key value false
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Moved] (VELTOOLS-209) velocity 1.7 vs velocity 2.3: evaluation of scripts with empty value is not backward compatible
[
https://issues.apache.org/jira/browse/VELTOOLS-209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson moved VELOCITY-956 to VELTOOLS-209:
--
Key: VELTOOLS-209 (was: VELOCITY-956)
Affects Version/s: 3.1
2.0
(was: 2.3)
Project: Velocity Tools (was: Velocity)
> velocity 1.7 vs velocity 2.3: evaluation of scripts with empty value is not
> backward compatible
> ---
>
> Key: VELTOOLS-209
> URL: https://issues.apache.org/jira/browse/VELTOOLS-209
> Project: Velocity Tools
> Issue Type: Bug
>Affects Versions: 3.1, 2.0
>Reporter: ambika
>Priority: Major
>
> {*}Script{*}:
>
> "vLATE_GATE_IN_6":"#set( $inTimeZone =
> $date.getTimeZone().getTimeZone('Europe/Berlin') )\n\n#set( $outTimeZone =
> $date.getTimeZone().getTimeZone('Asia/Shanghai') )\n\n#set( $locale =
> $date.getLocale() )\n\n#set( $myDate =
> $convert.parseDate(${*}{lead.lateGateIn}{*},\"-MM-dd
> HH:mm\",$locale,$inTimeZone) )\n\n${date.format('-MM-dd hh:mm
> a',$myDate,$locale,$outTimeZone)} "
> {*}note{*}: lead.lateGateIn = "" in the values
> there are multiple other scripts vLATE_GATE_IN_5, vLATE_GATE_IN_4 but in the
> script vLATE_GATE_IN_4 , the values for convert.parseDate is given as below:
> $convert.parseDate("2022-04-22")
>
> {*}Issue{*}:
> Older version of velocity evaluates the script vLATE_GATE_IN_6 to:
> |Time):\\n\\n\\n\\n\\n2022-04-22 11:00 AM|
>
> Newer version of velocity evaluates the script vLATE_GATE_IN_6 to:
> | |Time):\\n\\n\\n\\n\\n${date.format('-MM-dd hh:mm
> a',$myDate,$locale,$outTimeZone)}| |
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-956) velocity 1.7 vs velocity 2.3: evaluation of scripts with empty value is not backward compatible
[
https://issues.apache.org/jira/browse/VELOCITY-956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson updated VELOCITY-956:
Component/s: (was: Engine)
(was: Scripting)
> velocity 1.7 vs velocity 2.3: evaluation of scripts with empty value is not
> backward compatible
> ---
>
> Key: VELOCITY-956
> URL: https://issues.apache.org/jira/browse/VELOCITY-956
> Project: Velocity
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: ambika
>Priority: Major
>
> {*}Script{*}:
>
> "vLATE_GATE_IN_6":"#set( $inTimeZone =
> $date.getTimeZone().getTimeZone('Europe/Berlin') )\n\n#set( $outTimeZone =
> $date.getTimeZone().getTimeZone('Asia/Shanghai') )\n\n#set( $locale =
> $date.getLocale() )\n\n#set( $myDate =
> $convert.parseDate(${*}{lead.lateGateIn}{*},\"-MM-dd
> HH:mm\",$locale,$inTimeZone) )\n\n${date.format('-MM-dd hh:mm
> a',$myDate,$locale,$outTimeZone)} "
> {*}note{*}: lead.lateGateIn = "" in the values
> there are multiple other scripts vLATE_GATE_IN_5, vLATE_GATE_IN_4 but in the
> script vLATE_GATE_IN_4 , the values for convert.parseDate is given as below:
> $convert.parseDate("2022-04-22")
>
> {*}Issue{*}:
> Older version of velocity evaluates the script vLATE_GATE_IN_6 to:
> |Time):\\n\\n\\n\\n\\n2022-04-22 11:00 AM|
>
> Newer version of velocity evaluates the script vLATE_GATE_IN_6 to:
> | |Time):\\n\\n\\n\\n\\n${date.format('-MM-dd hh:mm
> a',$myDate,$locale,$outTimeZone)}| |
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-956) velocity 1.7 vs velocity 2.3: evaluation of scripts with empty value is not backward compatible
[
https://issues.apache.org/jira/browse/VELOCITY-956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876411#comment-17876411
]
Claude Brisson commented on VELOCITY-956:
-
I have the following test template:
{code}
#set( $inTimeZone = $date.getTimeZone().getTimeZone('Europe/Berlin') )
#set( $outTimeZone = $date.getTimeZone().getTimeZone('Asia/Shanghai') )
#set( $locale = $date.getLocale() )
#set( $myDate = $convert.parseDate("2022-04-22 00:00","-MM-dd
HH:mm",$locale,$inTimeZone))
inTimeZone = $inTimeZone
outTimeZone = $outTimeZone
locale = $locale
myDate = $myDate
${date.format('-MM-dd hh:mm a',$myDate,$locale,$outTimeZone)}
{code}
I could not exactly reproduce your problem: with engine 2.3 and tools 3.1, as
well with engine 1.7 and tools 2.0, the call $convert.parseDate returns null, I
don't investigate further for now, I'm focusing on the engine issues.
> velocity 1.7 vs velocity 2.3: evaluation of scripts with empty value is not
> backward compatible
> ---
>
> Key: VELOCITY-956
> URL: https://issues.apache.org/jira/browse/VELOCITY-956
> Project: Velocity
> Issue Type: Bug
> Components: Engine, Scripting
>Affects Versions: 2.3
>Reporter: ambika
>Priority: Major
>
> {*}Script{*}:
>
> "vLATE_GATE_IN_6":"#set( $inTimeZone =
> $date.getTimeZone().getTimeZone('Europe/Berlin') )\n\n#set( $outTimeZone =
> $date.getTimeZone().getTimeZone('Asia/Shanghai') )\n\n#set( $locale =
> $date.getLocale() )\n\n#set( $myDate =
> $convert.parseDate(${*}{lead.lateGateIn}{*},\"-MM-dd
> HH:mm\",$locale,$inTimeZone) )\n\n${date.format('-MM-dd hh:mm
> a',$myDate,$locale,$outTimeZone)} "
> {*}note{*}: lead.lateGateIn = "" in the values
> there are multiple other scripts vLATE_GATE_IN_5, vLATE_GATE_IN_4 but in the
> script vLATE_GATE_IN_4 , the values for convert.parseDate is given as below:
> $convert.parseDate("2022-04-22")
>
> {*}Issue{*}:
> Older version of velocity evaluates the script vLATE_GATE_IN_6 to:
> |Time):\\n\\n\\n\\n\\n2022-04-22 11:00 AM|
>
> Newer version of velocity evaluates the script vLATE_GATE_IN_6 to:
> | |Time):\\n\\n\\n\\n\\n${date.format('-MM-dd hh:mm
> a',$myDate,$locale,$outTimeZone)}| |
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-962) Unclosed #[[ is no longer an error
[
https://issues.apache.org/jira/browse/VELOCITY-962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876350#comment-17876350
]
Nathan Bubna commented on VELOCITY-962:
---
I think it would be better to error. It would be all too easy to delete a
closing ]]# and have have following template syntax treated as literal.
> Unclosed #[[ is no longer an error
> --
>
> Key: VELOCITY-962
> URL: https://issues.apache.org/jira/browse/VELOCITY-962
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Éamonn McManus
>Priority: Minor
>
> With Velocity 1.7, if you had {{#[[ without ]]#}} then you would get an
> exception like this:
> {noformat}
> org.apache.velocity.runtime.parser.ParseException: Lexical error:
> org.apache.velocity.runtime.parser.TokenMgrError: Lexical error at line 4,
> column 5. Encountered: after : ""
> at org.apache.velocity.runtime.parser.Parser.parse(Parser.java:136)
> at
> org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:1226)
> at
> org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:1181){noformat}
> However, with 2.3 this is just silently accepted. I think it would be better
> to continue to throw an exception, and better still if the exception message
> indicated where the {{#[[}} started.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-962) Unclosed #[[ is no longer an error
[
https://issues.apache.org/jira/browse/VELOCITY-962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876350#comment-17876350
]
Nathan Bubna edited comment on VELOCITY-962 at 8/23/24 7:13 PM:
I think it would be better to error. It would be all too easy to delete a
closing ]]# and have following template syntax treated as literal.
was (Author: nbubna):
I think it would be better to error. It would be all too easy to delete a
closing ]]# and have have following template syntax treated as literal.
> Unclosed #[[ is no longer an error
> --
>
> Key: VELOCITY-962
> URL: https://issues.apache.org/jira/browse/VELOCITY-962
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Éamonn McManus
>Priority: Minor
>
> With Velocity 1.7, if you had {{#[[ without ]]#}} then you would get an
> exception like this:
> {noformat}
> org.apache.velocity.runtime.parser.ParseException: Lexical error:
> org.apache.velocity.runtime.parser.TokenMgrError: Lexical error at line 4,
> column 5. Encountered: after : ""
> at org.apache.velocity.runtime.parser.Parser.parse(Parser.java:136)
> at
> org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:1226)
> at
> org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:1181){noformat}
> However, with 2.3 this is just silently accepted. I think it would be better
> to continue to throw an exception, and better still if the exception message
> indicated where the {{#[[}} started.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-962) Unclosed #[[ is no longer an error
[
https://issues.apache.org/jira/browse/VELOCITY-962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876345#comment-17876345
]
Claude Brisson commented on VELOCITY-962:
-
I'm unsure about this one. Hitting the end of the document could implicitly
close the verbatim section.
> Unclosed #[[ is no longer an error
> --
>
> Key: VELOCITY-962
> URL: https://issues.apache.org/jira/browse/VELOCITY-962
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Éamonn McManus
>Priority: Minor
>
> With Velocity 1.7, if you had {{#[[ without ]]#}} then you would get an
> exception like this:
> {noformat}
> org.apache.velocity.runtime.parser.ParseException: Lexical error:
> org.apache.velocity.runtime.parser.TokenMgrError: Lexical error at line 4,
> column 5. Encountered: after : ""
> at org.apache.velocity.runtime.parser.Parser.parse(Parser.java:136)
> at
> org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:1226)
> at
> org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:1181){noformat}
> However, with 2.3 this is just silently accepted. I think it would be better
> to continue to throw an exception, and better still if the exception message
> indicated where the {{#[[}} started.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-982) Velocity 2.x - Velocity.properties - Additional introspector.restrict.classes
[ https://issues.apache.org/jira/browse/VELOCITY-982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876343#comment-17876343 ] Nathan Bubna commented on VELOCITY-982: --- We would be happy to get a PR to update the secure introspector's entries. I've never trusted third-party templates myself (most users don't), but i know there are those who still rely on this and would appreciate the default list being updated, so they needn't add these themselves. And no, Velocity is still an active project, not CVE patch mode only. It's not a very active project, granted. The contributors are fairly satisfied (read: not highly motivated to put substantial work into it), but we do still have ongoing (slow, sporadic) development. > Velocity 2.x - Velocity.properties - Additional introspector.restrict.classes > - > > Key: VELOCITY-982 > URL: https://issues.apache.org/jira/browse/VELOCITY-982 > Project: Velocity > Issue Type: Improvement > Components: Build >Affects Versions: 2.0, 2.1, 2.2, 2.3, 2.4.2 >Reporter: John Tal >Priority: Major > > In Velocity.properties, the introspector.restrict.classes entries. > I assume additions to this file in that section resolved for CVE-2020-13936 > (templating can interact with the system)? Please confirm what commits or > classes, settings did indeed resolve CVE-2020-13936. We really need to know > because we are stuck on 1.7 and need to fork/patch. > Along these lines of further security hardening, aren't there more entries > needed in the introspect.restrict.classes section such as: > java.lang.ProcessBuilder > java.lang.Reflect > javax.management.MBeanServer > java.net.Socket > javax.script.ScriptEngine > > Finally, please confirm whether Velocity is largely in CVE patch mode only > and is not really an active project given that there is much more talk today > about Apache FreeMarker. Just trying to determine the level of support and > engagement from the Apache Velocity maintainers. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Closed] (VELOCITY-961) Parsing regression in Velocity 2.3
[
https://issues.apache.org/jira/browse/VELOCITY-961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson closed VELOCITY-961.
---
Fix Version/s: 2.4
Resolution: Fixed
Fixed, see [corresponding PR|https://github.com/apache/velocity-engine/pull/47].
> Parsing regression in Velocity 2.3
> --
>
> Key: VELOCITY-961
> URL: https://issues.apache.org/jira/browse/VELOCITY-961
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Éamonn McManus
>Assignee: Claude Brisson
>Priority: Minor
> Fix For: 2.4
>
>
> The following template parses correctly with Velocity 1.7:
> {noformat}
> $child.typeName()#if($child.isRepeated())[]#end{noformat}
> But with 2.3 it gets an exception:
> {noformat}
> org.apache.velocity.runtime.parser.TemplateParseException: Encountered "[" at
> velocityParsingBug[line 1, column 42]
> Was expecting one of:
> "\u001c" ...
> "\u001c" ...
> "||" ...
> "|" ...
> "(" ...
> ")" ...
> ...
> "]]#" ...
> ...
> ...
> ...
> ...
> ...
> ...
> ...
> "{" ...
> "}" ...
> "" ...
> "\\" ...
> ...
> ...
> ...
> "{" ...
> "\u001c" ...
> ...
> ... at
> org.apache.velocity.runtime.parser.StandardParser.parse(StandardParser.java:198)
> at
> org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:1341){noformat}
> I think the template is correct and should work with both versions.
> I was able to work around the bug like this:
> {noformat}
> $set ($squares = '[]')
> $child.typeName()#if($child.isRepeated())$squares#end{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] (VELOCITY-961) Parsing regression in Velocity 2.3
[ https://issues.apache.org/jira/browse/VELOCITY-961 ]
Claude Brisson deleted comment on VELOCITY-961:
-
was (Author: claude):
Resolved with the new runtime.immutable_ranges backward
compatibility configuration flag, see [the corresponding
PR|https://github.com/apache/velocity-engine/pull/46]
> Parsing regression in Velocity 2.3
> --
>
> Key: VELOCITY-961
> URL: https://issues.apache.org/jira/browse/VELOCITY-961
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Éamonn McManus
>Assignee: Claude Brisson
>Priority: Minor
>
> The following template parses correctly with Velocity 1.7:
> {noformat}
> $child.typeName()#if($child.isRepeated())[]#end{noformat}
> But with 2.3 it gets an exception:
> {noformat}
> org.apache.velocity.runtime.parser.TemplateParseException: Encountered "[" at
> velocityParsingBug[line 1, column 42]
> Was expecting one of:
> "\u001c" ...
> "\u001c" ...
> "||" ...
> "|" ...
> "(" ...
> ")" ...
> ...
> "]]#" ...
> ...
> ...
> ...
> ...
> ...
> ...
> ...
> "{" ...
> "}" ...
> "" ...
> "\\" ...
> ...
> ...
> ...
> "{" ...
> "\u001c" ...
> ...
> ... at
> org.apache.velocity.runtime.parser.StandardParser.parse(StandardParser.java:198)
> at
> org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:1341){noformat}
> I think the template is correct and should work with both versions.
> I was able to work around the bug like this:
> {noformat}
> $set ($squares = '[]')
> $child.typeName()#if($child.isRepeated())$squares#end{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] (VELOCITY-961) Parsing regression in Velocity 2.3
[ https://issues.apache.org/jira/browse/VELOCITY-961 ]
Claude Brisson deleted comment on VELOCITY-961:
-
was (Author: claude):
Ooops, wrong issue
> Parsing regression in Velocity 2.3
> --
>
> Key: VELOCITY-961
> URL: https://issues.apache.org/jira/browse/VELOCITY-961
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Éamonn McManus
>Assignee: Claude Brisson
>Priority: Minor
>
> The following template parses correctly with Velocity 1.7:
> {noformat}
> $child.typeName()#if($child.isRepeated())[]#end{noformat}
> But with 2.3 it gets an exception:
> {noformat}
> org.apache.velocity.runtime.parser.TemplateParseException: Encountered "[" at
> velocityParsingBug[line 1, column 42]
> Was expecting one of:
> "\u001c" ...
> "\u001c" ...
> "||" ...
> "|" ...
> "(" ...
> ")" ...
> ...
> "]]#" ...
> ...
> ...
> ...
> ...
> ...
> ...
> ...
> "{" ...
> "}" ...
> "" ...
> "\\" ...
> ...
> ...
> ...
> "{" ...
> "\u001c" ...
> ...
> ... at
> org.apache.velocity.runtime.parser.StandardParser.parse(StandardParser.java:198)
> at
> org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:1341){noformat}
> I think the template is correct and should work with both versions.
> I was able to work around the bug like this:
> {noformat}
> $set ($squares = '[]')
> $child.typeName()#if($child.isRepeated())$squares#end{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Closed] (VELOCITY-948) Number ranges created as ASTIntegerRange$IntegerRange in 2.1 rather than java.util.ArrayList
[
https://issues.apache.org/jira/browse/VELOCITY-948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson closed VELOCITY-948.
---
Fix Version/s: 2.4
Resolution: Fixed
Resolved with the new runtime.immutable_ranges backward
compatibility configuration flag, see [the corresponding
PR|https://github.com/apache/velocity-engine/pull/46]
> Number ranges created as ASTIntegerRange$IntegerRange in 2.1 rather than
> java.util.ArrayList
>
>
> Key: VELOCITY-948
> URL: https://issues.apache.org/jira/browse/VELOCITY-948
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.1
>Reporter: Tom White
>Priority: Minor
> Fix For: 2.4
>
>
> Hello!
> I am having issues upgrading from 2.0 to 2.1 with existing templates. The
> minimal below example illustrates the change in behaviour:
> {code:java}
>
>
> #set ($example= [0..50])
> ${example.class.name}
> #set ($example[10] = 500)
>
>
> {code}
>
> With 2.0:
> this prints:
> java.util.ArrayList
> and throws no errors.
>
> With 2.1:
> this prints:
> org.apache.velocity.runtime.parser.node.ASTIntegerRange$IntegerRange
> and throws an UnsupportedMethodException at the set line.
>
> I have tried all kinds of config variables from the docs in a unit test.
> The 2.1 documentation states:
> * The VTL RangeOperator [ 1..10 ] and ObjectArray ["a","b"] are
> {{java.util.ArrayList}} objects when placed in the context or passed to
> methods. Therefore, your methods that are designed to accept arrays created
> in the template should be written with this in mind.
> [https://velocity.apache.org/engine/2.1/developer-guide.html]
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-961) Parsing regression in Velocity 2.3
[
https://issues.apache.org/jira/browse/VELOCITY-961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson updated VELOCITY-961:
Fix Version/s: (was: 2.4)
> Parsing regression in Velocity 2.3
> --
>
> Key: VELOCITY-961
> URL: https://issues.apache.org/jira/browse/VELOCITY-961
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Éamonn McManus
>Assignee: Claude Brisson
>Priority: Minor
>
> The following template parses correctly with Velocity 1.7:
> {noformat}
> $child.typeName()#if($child.isRepeated())[]#end{noformat}
> But with 2.3 it gets an exception:
> {noformat}
> org.apache.velocity.runtime.parser.TemplateParseException: Encountered "[" at
> velocityParsingBug[line 1, column 42]
> Was expecting one of:
> "\u001c" ...
> "\u001c" ...
> "||" ...
> "|" ...
> "(" ...
> ")" ...
> ...
> "]]#" ...
> ...
> ...
> ...
> ...
> ...
> ...
> ...
> "{" ...
> "}" ...
> "" ...
> "\\" ...
> ...
> ...
> ...
> "{" ...
> "\u001c" ...
> ...
> ... at
> org.apache.velocity.runtime.parser.StandardParser.parse(StandardParser.java:198)
> at
> org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:1341){noformat}
> I think the template is correct and should work with both versions.
> I was able to work around the bug like this:
> {noformat}
> $set ($squares = '[]')
> $child.typeName()#if($child.isRepeated())$squares#end{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-961) Parsing regression in Velocity 2.3
[
https://issues.apache.org/jira/browse/VELOCITY-961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson updated VELOCITY-961:
Fix Version/s: 2.4
> Parsing regression in Velocity 2.3
> --
>
> Key: VELOCITY-961
> URL: https://issues.apache.org/jira/browse/VELOCITY-961
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Éamonn McManus
>Assignee: Claude Brisson
>Priority: Minor
> Fix For: 2.4
>
>
> The following template parses correctly with Velocity 1.7:
> {noformat}
> $child.typeName()#if($child.isRepeated())[]#end{noformat}
> But with 2.3 it gets an exception:
> {noformat}
> org.apache.velocity.runtime.parser.TemplateParseException: Encountered "[" at
> velocityParsingBug[line 1, column 42]
> Was expecting one of:
> "\u001c" ...
> "\u001c" ...
> "||" ...
> "|" ...
> "(" ...
> ")" ...
> ...
> "]]#" ...
> ...
> ...
> ...
> ...
> ...
> ...
> ...
> "{" ...
> "}" ...
> "" ...
> "\\" ...
> ...
> ...
> ...
> "{" ...
> "\u001c" ...
> ...
> ... at
> org.apache.velocity.runtime.parser.StandardParser.parse(StandardParser.java:198)
> at
> org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:1341){noformat}
> I think the template is correct and should work with both versions.
> I was able to work around the bug like this:
> {noformat}
> $set ($squares = '[]')
> $child.typeName()#if($child.isRepeated())$squares#end{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Reopened] (VELOCITY-961) Parsing regression in Velocity 2.3
[
https://issues.apache.org/jira/browse/VELOCITY-961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson reopened VELOCITY-961:
-
Ooops, wrong issue
> Parsing regression in Velocity 2.3
> --
>
> Key: VELOCITY-961
> URL: https://issues.apache.org/jira/browse/VELOCITY-961
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Éamonn McManus
>Assignee: Claude Brisson
>Priority: Minor
> Fix For: 2.4
>
>
> The following template parses correctly with Velocity 1.7:
> {noformat}
> $child.typeName()#if($child.isRepeated())[]#end{noformat}
> But with 2.3 it gets an exception:
> {noformat}
> org.apache.velocity.runtime.parser.TemplateParseException: Encountered "[" at
> velocityParsingBug[line 1, column 42]
> Was expecting one of:
> "\u001c" ...
> "\u001c" ...
> "||" ...
> "|" ...
> "(" ...
> ")" ...
> ...
> "]]#" ...
> ...
> ...
> ...
> ...
> ...
> ...
> ...
> "{" ...
> "}" ...
> "" ...
> "\\" ...
> ...
> ...
> ...
> "{" ...
> "\u001c" ...
> ...
> ... at
> org.apache.velocity.runtime.parser.StandardParser.parse(StandardParser.java:198)
> at
> org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:1341){noformat}
> I think the template is correct and should work with both versions.
> I was able to work around the bug like this:
> {noformat}
> $set ($squares = '[]')
> $child.typeName()#if($child.isRepeated())$squares#end{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Closed] (VELOCITY-961) Parsing regression in Velocity 2.3
[
https://issues.apache.org/jira/browse/VELOCITY-961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson closed VELOCITY-961.
---
Resolution: Fixed
Resolved with the new runtime.immutable_ranges backward
compatibility configuration flag, see [the corresponding
PR|https://github.com/apache/velocity-engine/pull/46]
> Parsing regression in Velocity 2.3
> --
>
> Key: VELOCITY-961
> URL: https://issues.apache.org/jira/browse/VELOCITY-961
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Éamonn McManus
>Priority: Minor
>
> The following template parses correctly with Velocity 1.7:
> {noformat}
> $child.typeName()#if($child.isRepeated())[]#end{noformat}
> But with 2.3 it gets an exception:
> {noformat}
> org.apache.velocity.runtime.parser.TemplateParseException: Encountered "[" at
> velocityParsingBug[line 1, column 42]
> Was expecting one of:
> "\u001c" ...
> "\u001c" ...
> "||" ...
> "|" ...
> "(" ...
> ")" ...
> ...
> "]]#" ...
> ...
> ...
> ...
> ...
> ...
> ...
> ...
> "{" ...
> "}" ...
> "" ...
> "\\" ...
> ...
> ...
> ...
> "{" ...
> "\u001c" ...
> ...
> ... at
> org.apache.velocity.runtime.parser.StandardParser.parse(StandardParser.java:198)
> at
> org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:1341){noformat}
> I think the template is correct and should work with both versions.
> I was able to work around the bug like this:
> {noformat}
> $set ($squares = '[]')
> $child.typeName()#if($child.isRepeated())$squares#end{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Assigned] (VELOCITY-961) Parsing regression in Velocity 2.3
[
https://issues.apache.org/jira/browse/VELOCITY-961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson reassigned VELOCITY-961:
---
Assignee: Claude Brisson
> Parsing regression in Velocity 2.3
> --
>
> Key: VELOCITY-961
> URL: https://issues.apache.org/jira/browse/VELOCITY-961
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
>Reporter: Éamonn McManus
>Assignee: Claude Brisson
>Priority: Minor
>
> The following template parses correctly with Velocity 1.7:
> {noformat}
> $child.typeName()#if($child.isRepeated())[]#end{noformat}
> But with 2.3 it gets an exception:
> {noformat}
> org.apache.velocity.runtime.parser.TemplateParseException: Encountered "[" at
> velocityParsingBug[line 1, column 42]
> Was expecting one of:
> "\u001c" ...
> "\u001c" ...
> "||" ...
> "|" ...
> "(" ...
> ")" ...
> ...
> "]]#" ...
> ...
> ...
> ...
> ...
> ...
> ...
> ...
> "{" ...
> "}" ...
> "" ...
> "\\" ...
> ...
> ...
> ...
> "{" ...
> "\u001c" ...
> ...
> ... at
> org.apache.velocity.runtime.parser.StandardParser.parse(StandardParser.java:198)
> at
> org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:1341){noformat}
> I think the template is correct and should work with both versions.
> I was able to work around the bug like this:
> {noformat}
> $set ($squares = '[]')
> $child.typeName()#if($child.isRepeated())$squares#end{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-943) File vs. classpath issues with Spring VelocityEngineFactory
[ https://issues.apache.org/jira/browse/VELOCITY-943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876317#comment-17876317 ] Claude Brisson commented on VELOCITY-943: - That would be great! > File vs. classpath issues with Spring VelocityEngineFactory > --- > > Key: VELOCITY-943 > URL: https://issues.apache.org/jira/browse/VELOCITY-943 > Project: Velocity > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Scott Cantor >Priority: Minor > Labels: spring > Attachments: VelocityEngineFactory.java > > > TL;DR, there's a nominal bug fix, and a possible improvement I can suggest, > for the Spring support you copied in from Spring 4 based on the copy we're > using in our project. Our copy differs in some slight ways so a straight > patch diff wasn't very obvious and I'm just going to attach our copy of the > file. > Full explanation: we ported the Spring support into our code for Spring 5 > before you had ported it in, and we were actually prepping a submission for > that but you pulled it in before we had a chance. There were some slight > improvements I made for our use, and today another issue in the same area of > the code got reported and fixed, and it's nominally a bug, so I thought I'd > try submitting that as a possible improvement along with my other change. > The issue is mainly around the way the Spring code combined use of the > File-based Velocity loader with the Spring loader by checking for filesystem > existence on the paths, in order to allow file-based usage to leverage > Velocity's support for template reloading. > In Spring's code (and now your code), there's an issue because it processes > each path via Spring ResourceLoader and then converts the Resource into a > File for an exists() test. If that passes, it installs the file-based loader > instead of the Spring loader. The problem/bug is that some containers unpack > jars, but only partially. Some kind of weird optimization I guess. The result > is that if some of the files get unpacked and not others, this code installs > the file loader and then that fails later because not all the files are there. > The fix seems to be to check for classpath: leading off the path and skip the > exists() check so that it will get deferred to the Spring loader. So that's a > fix, nominally, though right now we've only seen this reported for Wildfly as > a container. > The related enhancement I made was that I allowed for both File-based and > Spring-based paths by walking the complete list and tracking each path set > individually and allowing both loaders to get installed into the Velocity > engine. That was needed for us to support both file-based templates along > with system templates we ship in jars. So as it, we have to have that feature > and can't use the original Spring code, so I'm hoping with the possible > justification of a bug fix, you might take the other change also. > All of the differences that aren't cosmetic are in the > initVelocityResourceLoader method, except that there's also a fix to > initSpringResourceLoader that changes a setProperty to addProperty so that > the Spring loader can get added to the set of loaders and not replace the > file loader. > Apologies that a diff would be so messy but hopefully given that the class is > simple and small, the differences will be clear enough with my explanation. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-943) File vs. classpath issues with Spring VelocityEngineFactory
[ https://issues.apache.org/jira/browse/VELOCITY-943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876307#comment-17876307 ] Scott Cantor commented on VELOCITY-943: --- Been a while, but time permitting I can see what I can come up with. We don't need the logic to be conditional, but I imagine I could design something that defaults to the original. If you're willing to take these changes, I'm willing to find some time at some point to come up with a patch against the code in the Velocity repo. > File vs. classpath issues with Spring VelocityEngineFactory > --- > > Key: VELOCITY-943 > URL: https://issues.apache.org/jira/browse/VELOCITY-943 > Project: Velocity > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Scott Cantor >Priority: Minor > Labels: spring > Attachments: VelocityEngineFactory.java > > > TL;DR, there's a nominal bug fix, and a possible improvement I can suggest, > for the Spring support you copied in from Spring 4 based on the copy we're > using in our project. Our copy differs in some slight ways so a straight > patch diff wasn't very obvious and I'm just going to attach our copy of the > file. > Full explanation: we ported the Spring support into our code for Spring 5 > before you had ported it in, and we were actually prepping a submission for > that but you pulled it in before we had a chance. There were some slight > improvements I made for our use, and today another issue in the same area of > the code got reported and fixed, and it's nominally a bug, so I thought I'd > try submitting that as a possible improvement along with my other change. > The issue is mainly around the way the Spring code combined use of the > File-based Velocity loader with the Spring loader by checking for filesystem > existence on the paths, in order to allow file-based usage to leverage > Velocity's support for template reloading. > In Spring's code (and now your code), there's an issue because it processes > each path via Spring ResourceLoader and then converts the Resource into a > File for an exists() test. If that passes, it installs the file-based loader > instead of the Spring loader. The problem/bug is that some containers unpack > jars, but only partially. Some kind of weird optimization I guess. The result > is that if some of the files get unpacked and not others, this code installs > the file loader and then that fails later because not all the files are there. > The fix seems to be to check for classpath: leading off the path and skip the > exists() check so that it will get deferred to the Spring loader. So that's a > fix, nominally, though right now we've only seen this reported for Wildfly as > a container. > The related enhancement I made was that I allowed for both File-based and > Spring-based paths by walking the complete list and tracking each path set > individually and allowing both loaders to get installed into the Velocity > engine. That was needed for us to support both file-based templates along > with system templates we ship in jars. So as it, we have to have that feature > and can't use the original Spring code, so I'm hoping with the possible > justification of a bug fix, you might take the other change also. > All of the differences that aren't cosmetic are in the > initVelocityResourceLoader method, except that there's also a fix to > initSpringResourceLoader that changes a setProperty to addProperty so that > the Spring loader can get added to the set of loaders and not replace the > file loader. > Apologies that a diff would be so messy but hopefully given that the class is > simple and small, the differences will be clear enough with my explanation. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-982) Velocity 2.x - Velocity.properties - Additional introspector.restrict.classes
[ https://issues.apache.org/jira/browse/VELOCITY-982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876284#comment-17876284 ] John Tal commented on VELOCITY-982: --- Also, per the original finding [https://securitylab.github.com/advisories/GHSL-2020-048-apache-velocity/] they exposed the vulnerability through java.script.ScriptEngineManager > Velocity 2.x - Velocity.properties - Additional introspector.restrict.classes > - > > Key: VELOCITY-982 > URL: https://issues.apache.org/jira/browse/VELOCITY-982 > Project: Velocity > Issue Type: Improvement > Components: Build >Affects Versions: 2.0, 2.1, 2.2, 2.3, 2.4.2 >Reporter: John Tal >Priority: Major > > In Velocity.properties, the introspector.restrict.classes entries. > I assume additions to this file in that section resolved for CVE-2020-13936 > (templating can interact with the system)? Please confirm what commits or > classes, settings did indeed resolve CVE-2020-13936. We really need to know > because we are stuck on 1.7 and need to fork/patch. > Along these lines of further security hardening, aren't there more entries > needed in the introspect.restrict.classes section such as: > java.lang.ProcessBuilder > java.lang.Reflect > javax.management.MBeanServer > java.net.Socket > javax.script.ScriptEngine > > Finally, please confirm whether Velocity is largely in CVE patch mode only > and is not really an active project given that there is much more talk today > about Apache FreeMarker. Just trying to determine the level of support and > engagement from the Apache Velocity maintainers. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-943) File vs. classpath issues with Spring VelocityEngineFactory
[ https://issues.apache.org/jira/browse/VELOCITY-943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17324576#comment-17324576 ] Michael Osipov edited comment on VELOCITY-943 at 8/23/24 7:57 AM: -- I appreciate the detailed report and submission. Thx! That said, I'm just interested in the Spring integration, not a committer like [~cbrisson] :) was (Author: timcolson): I appreciate the detailed report and submission. Thx! That said, I'm just interested in the Spring integration, not a committer like [~cbrisson] :) > File vs. classpath issues with Spring VelocityEngineFactory > --- > > Key: VELOCITY-943 > URL: https://issues.apache.org/jira/browse/VELOCITY-943 > Project: Velocity > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Scott Cantor >Priority: Minor > Labels: spring > Attachments: VelocityEngineFactory.java > > > TL;DR, there's a nominal bug fix, and a possible improvement I can suggest, > for the Spring support you copied in from Spring 4 based on the copy we're > using in our project. Our copy differs in some slight ways so a straight > patch diff wasn't very obvious and I'm just going to attach our copy of the > file. > Full explanation: we ported the Spring support into our code for Spring 5 > before you had ported it in, and we were actually prepping a submission for > that but you pulled it in before we had a chance. There were some slight > improvements I made for our use, and today another issue in the same area of > the code got reported and fixed, and it's nominally a bug, so I thought I'd > try submitting that as a possible improvement along with my other change. > The issue is mainly around the way the Spring code combined use of the > File-based Velocity loader with the Spring loader by checking for filesystem > existence on the paths, in order to allow file-based usage to leverage > Velocity's support for template reloading. > In Spring's code (and now your code), there's an issue because it processes > each path via Spring ResourceLoader and then converts the Resource into a > File for an exists() test. If that passes, it installs the file-based loader > instead of the Spring loader. The problem/bug is that some containers unpack > jars, but only partially. Some kind of weird optimization I guess. The result > is that if some of the files get unpacked and not others, this code installs > the file loader and then that fails later because not all the files are there. > The fix seems to be to check for classpath: leading off the path and skip the > exists() check so that it will get deferred to the Spring loader. So that's a > fix, nominally, though right now we've only seen this reported for Wildfly as > a container. > The related enhancement I made was that I allowed for both File-based and > Spring-based paths by walking the complete list and tracking each path set > individually and allowing both loaders to get installed into the Velocity > engine. That was needed for us to support both file-based templates along > with system templates we ship in jars. So as it, we have to have that feature > and can't use the original Spring code, so I'm hoping with the possible > justification of a bug fix, you might take the other change also. > All of the differences that aren't cosmetic are in the > initVelocityResourceLoader method, except that there's also a fix to > initSpringResourceLoader that changes a setProperty to addProperty so that > the Spring loader can get added to the set of loaders and not replace the > file loader. > Apologies that a diff would be so messy but hopefully given that the class is > simple and small, the differences will be clear enough with my explanation. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-943) File vs. classpath issues with Spring VelocityEngineFactory
[ https://issues.apache.org/jira/browse/VELOCITY-943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876199#comment-17876199 ] Claude Brisson commented on VELOCITY-943: - Basically, what you are describing is a change in the default behavior for resources loaders configuration. Instead of tweaking this default one way or another, I think it would be more convenient to let the user explicitly choose the expected behavior, to avoid any surprise. [~scantor] do you think you could help me define a specification for such a configuration that would avoid having to deal with such default behaviors? I am not a spring user myself, so maintaining the Velocity spring module is not easy if no one is stepping in. > File vs. classpath issues with Spring VelocityEngineFactory > --- > > Key: VELOCITY-943 > URL: https://issues.apache.org/jira/browse/VELOCITY-943 > Project: Velocity > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Scott Cantor >Priority: Minor > Labels: spring > Attachments: VelocityEngineFactory.java > > > TL;DR, there's a nominal bug fix, and a possible improvement I can suggest, > for the Spring support you copied in from Spring 4 based on the copy we're > using in our project. Our copy differs in some slight ways so a straight > patch diff wasn't very obvious and I'm just going to attach our copy of the > file. > Full explanation: we ported the Spring support into our code for Spring 5 > before you had ported it in, and we were actually prepping a submission for > that but you pulled it in before we had a chance. There were some slight > improvements I made for our use, and today another issue in the same area of > the code got reported and fixed, and it's nominally a bug, so I thought I'd > try submitting that as a possible improvement along with my other change. > The issue is mainly around the way the Spring code combined use of the > File-based Velocity loader with the Spring loader by checking for filesystem > existence on the paths, in order to allow file-based usage to leverage > Velocity's support for template reloading. > In Spring's code (and now your code), there's an issue because it processes > each path via Spring ResourceLoader and then converts the Resource into a > File for an exists() test. If that passes, it installs the file-based loader > instead of the Spring loader. The problem/bug is that some containers unpack > jars, but only partially. Some kind of weird optimization I guess. The result > is that if some of the files get unpacked and not others, this code installs > the file loader and then that fails later because not all the files are there. > The fix seems to be to check for classpath: leading off the path and skip the > exists() check so that it will get deferred to the Spring loader. So that's a > fix, nominally, though right now we've only seen this reported for Wildfly as > a container. > The related enhancement I made was that I allowed for both File-based and > Spring-based paths by walking the complete list and tracking each path set > individually and allowing both loaders to get installed into the Velocity > engine. That was needed for us to support both file-based templates along > with system templates we ship in jars. So as it, we have to have that feature > and can't use the original Spring code, so I'm hoping with the possible > justification of a bug fix, you might take the other change also. > All of the differences that aren't cosmetic are in the > initVelocityResourceLoader method, except that there's also a fix to > initSpringResourceLoader that changes a setProperty to addProperty so that > the Spring loader can get added to the set of loaders and not replace the > file loader. > Apologies that a diff would be so messy but hopefully given that the class is > simple and small, the differences will be clear enough with my explanation. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
