velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Charles Oliver Nutter <>
Subject Re: Unable to locate .VM files in Jar (Velocity 1.3.1)
Date Fri, 31 Oct 2003 17:02:31 GMT
I like option 3: use both classloaders. If all is done like it should 
be, the context classloader will get the resource just fine. That ought 
to cover most cases. If it fails, we can fall back to the old method.

I agree, I'd rather not have another resource loader...just imagine the 
questions on the list about which ClasspathResourceLoader to use. Plus, 
unless people understand thread-context class loaders, they'll still use 
the old one and have it not work.

If we must create a new one, I'd say "ThreadContextResourceLoader" is 
about as clear as can be.

- Charlie

Geir Magnusson Jr. wrote:

> On Friday, October 31, 2003, at 09:44 AM, Geir Magnusson Jr. wrote:
>> Hoo boy.  Here's the beef.  Ant doesn't set the context classloader
>> so Thread.currentThread().getContextClassloader()
>> return the primordial classloader, which of course, doesn't have the 
>> classpath that you set in the ant build script.  I you use the canonical
>> this.getClass().getClassloader()
>> you get the ant classloader, which has your classpath.
>> I'm asking the ant crew about what to do.
> I talked to the ant team, and this is fixed in ant 1.6.  What this 
> means is
> a) if we make this change, we need to use ant 1.6 to test with and we 
> run a significant risk of breaking other things where [strange, IMO] 
> things are done with the classloader.  I don't like either of those.  
> I was darn happy w/ ant 1.4, and we don't want to break things.
> or
> b) We add a new class, ContextClasspathResourceLoader
> As much as I *hate* adding a new loader, it's the only way I can 
> imagine that we do this w/o breaking someone, and quite frankly, 
> classloader bugs are amazingly hard to track down sometimes..
> geir

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message