Fyi. I filed a bug with Velocity as well:
https://issues.apache.org/jira/browse/VELOCITY-827
Dawid
On Sat, May 26, 2012 at 11:10 PM, Benson Margulies
wrote:
> Velocity has a nasty reputation for problems on the classpath. I've
> fought with it on CXF.
>
> However, if I'm right, the immediate pro
Velocity has a nasty reputation for problems on the classpath. I've
fought with it on CXF.
However, if I'm right, the immediate problem is trivial to fix.
In SimpleRelocator, I added this || clause to 'canRelocatePath'. If no
one pipes up with a reason why this would cause a disaster, I'm going
t
> That log message, however, is nuts. Searching in classpath and then
> logging that file path? I'd file that as a bug in Velocity.
It is definitely an bad code pattern -- should be either
class-relative resource or searched via
classloader, not class + '/' prefix). I see this from time to time
th
On Sat, May 26, 2012 at 1:31 PM, Dawid Weiss wrote:
> Ideally, this should be configurable via plugins because there is
> simply no way to predict what people may come up with?
As far as I can see, a very simple change to shade allows a/b/c to
match /a/b/c, and I have yet to think of a problem wi
Ideally, this should be configurable via plugins because there is
simply no way to predict what people may come up with?
The relevant fragment from velocity is not even consistent -- look:
inputStream =
getClass().getResourceAsStream("/org/apache/velocity/runtime/defaults/velocity.properties");
The problem here is that we need to relocate /a/b/c to /q/r/s.
However, since relocations are stated in terms of a.b.c form and not
path form, there's no syntax that maps.
Unless, of course, a pattern of a.b.c -> q.r.s should just work for
getClass().getResource("/a/b/c");
It seems reasonable to
