[
https://issues.apache.org/jira/browse/VELOCITY-943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17879039#comment-17879039
]
Scott Cantor commented on VELOCITY-943:
---------------------------------------
It does that now, the original file-based one is used in place of the Spring
loader in many cases. The problem is that it's either/or, which is not really
useful, whereas my patch just makes them both work in parallel (with the new
flag set anyway).
My argument is basically that if you didn't want the Spring loader, you
wouldn't configure it in the first place.
Bear in mind, this code isn't the thing implementing the Spring loader. That's
a different class. This code is used to auto-configure a Velocity engine with
the "right" resource loader(s) based on a set of resource paths. It's making a
decision about which loader(s) to install.
The original version picks between them (improperly) and only gives you one. My
patch just allows them both to be installed.
The other way this would be done is by having people manually configure their
own VelocityEngine with exactly the loaders they want and the paths to use. I
think that's already probably possible without this class, this is just a
shorthand for that so you can hand it a big path and let it figure out what to
do.
It would be entirely defensible to just say "forget about files here", and then
the class probably just goes away, but for whatever reason the original author
tried to make it "smarter" and didn't do that correctly in a few different
respects.
> File vs. classpath issues with Spring VelocityEngineFactory
> -----------------------------------------------------------
>
> Key: VELOCITY-943
> URL: https://issues.apache.org/jira/browse/VELOCITY-943
> Project: Velocity
> Issue Type: Improvement
> Affects Versions: 2.3
> Reporter: Scott Cantor
> Priority: Minor
> Labels: spring
> Attachments: VelocityEngineFactory.java
>
>
> TL;DR, there's a nominal bug fix, and a possible improvement I can suggest,
> for the Spring support you copied in from Spring 4 based on the copy we're
> using in our project. Our copy differs in some slight ways so a straight
> patch diff wasn't very obvious and I'm just going to attach our copy of the
> file.
> Full explanation: we ported the Spring support into our code for Spring 5
> before you had ported it in, and we were actually prepping a submission for
> that but you pulled it in before we had a chance. There were some slight
> improvements I made for our use, and today another issue in the same area of
> the code got reported and fixed, and it's nominally a bug, so I thought I'd
> try submitting that as a possible improvement along with my other change.
> The issue is mainly around the way the Spring code combined use of the
> File-based Velocity loader with the Spring loader by checking for filesystem
> existence on the paths, in order to allow file-based usage to leverage
> Velocity's support for template reloading.
> In Spring's code (and now your code), there's an issue because it processes
> each path via Spring ResourceLoader and then converts the Resource into a
> File for an exists() test. If that passes, it installs the file-based loader
> instead of the Spring loader. The problem/bug is that some containers unpack
> jars, but only partially. Some kind of weird optimization I guess. The result
> is that if some of the files get unpacked and not others, this code installs
> the file loader and then that fails later because not all the files are there.
> The fix seems to be to check for classpath: leading off the path and skip the
> exists() check so that it will get deferred to the Spring loader. So that's a
> fix, nominally, though right now we've only seen this reported for Wildfly as
> a container.
> The related enhancement I made was that I allowed for both File-based and
> Spring-based paths by walking the complete list and tracking each path set
> individually and allowing both loaders to get installed into the Velocity
> engine. That was needed for us to support both file-based templates along
> with system templates we ship in jars. So as it, we have to have that feature
> and can't use the original Spring code, so I'm hoping with the possible
> justification of a bug fix, you might take the other change also.
> All of the differences that aren't cosmetic are in the
> initVelocityResourceLoader method, except that there's also a fix to
> initSpringResourceLoader that changes a setProperty to addProperty so 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
