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