RE: ClassLoader resource loading of templates, for the record ( and perhaps for the next release?)

["Nutter, Charles O." <Ch...@fns.usda.gov>]

According to the javadoc for WebappLoader, it's for loading from the filesystem (or the virtual filesystem the webapp knows about), but using the webapp root as the base search path. That is certainly useful, for situations where the templates are packed into a webapp loose (i.e. not jarred), and may solve the problem there. Unfortunately, it doesn't solve my case (templates are packed into EJB jar), or any other case where the template is in a jar file (in WEB-INF/lib/myTemplateLibrary.jar, for example). There still needs to be a ClassLoader resource-based ResourceLoader that uses the correct ClassLoader for the calling thread.

- Charlie

-----Original Message-----
From: Mike Curwen [mailto:gb_dev@gb-im.com]
Sent: Thursday, August 07, 2003 4:38 PM
To: 'Velocity Users List'
Subject: RE: ClassLoader resource loading of templates, for the record (
and perhaps for the next release?)


I'm not sure why Nathan hasn't spoken up yet (perhaps he's on holidays?)
but doesn't the velocity-tools project's "WebappLoader" fix this
problem?
 
I'm not certain, because I've not made the move to velo-tools.



> -----Original Message-----
> From: Nutter, Charles O. [mailto:Charles.Nutter@fns.usda.gov] 
> Sent: Thursday, August 07, 2003 4:21 PM
> To: velocity-user@jakarta.apache.org
> Subject: ClassLoader resource loading of templates, for the 
> record (and perhaps for the next release?)
> 
> 
> (Sorry if this sort of thing should be posted to -dev, but I 
> wanted to toss it out for comments first :)
> 
> I managed to create a resource loader that does what I need to.
> 
> I see the following problems with ClasspathResourceLoader:
> 
> 1. It loads templates using the ClassLoader it was loaded in, 
> which in many cases will be the top-level or a high-level 
> ClassLoader within an appserver 2. Individual applications 
> within the server almost always are given their own 
> contextual ClassLoader. In Tomcat, for example, each webapp 
> has its own loader. 3. Each webapp should be able to package 
> templates in jars to be put in WEB-INF/lib and have Velocity 
> load them correctly. 4. Each webapp should not have to put 
> velocity-xxx.jar in their WEB-INF/lib to be able to use 
> Velocity. 5. Therefore, Velocity should be able to load 
> templates using the contextual ClassLoader appropriate for 
> the *caller*
> 
> ClasspathResourceLoader uses getClass().getClassLoader() to 
> look for templates. If Velocity is loaded at the system or 
> server level, and a webapp hopes to use this method to load 
> its own jarred templates, it will fail as it did for me.
> 
> The fix is terribly simple, and I think it makes sense to 
> apply it directly to ClasspathResourceLoader, or at least 
> provide a ThreadContextResourceLoader, as I have done:
> 
> In ClasspathResourceLoader.getResourceStream(), change:
> 
> ClassLoader classLoader = this.getClass().getClassLoader();
> 
> to:
> 
> ClassLoader classLoader = 
> Thread.currentThread().getContextClassLoader();
> 
> This will cause the resource loading to look first at the 
> caller's level (webapp) and if not found, move up the 
> ClassLoader chain. I believe this is the appropriate way to 
> handle loading templates as resources. From the documentation 
> for getContextClassLoader():
> 
>      * Returns the context ClassLoader for this Thread. The context
>      * ClassLoader is provided by the creator of the thread for use
>      * by code running in this thread when loading classes 
> and resources.
>      * If not set, the default is the ClassLoader context of 
> the parent
>      * Thread. The context ClassLoader of the primordial thread is
>      * typically set to the class loader used to load the application.
> 
> The resource should be loaded from the ClassLoader that the 
> creator of the calling thread intended...not from the system 
> classloader. Also keep in mind this change would not break 
> loading from the system classpath...it would just include 
> contextual ClassLoaders in the lookup process.
> 
> Comments? Questions? Flames? What do I have to do to convince 
> the Velocity guys this needs to go in? :)
> 
> - Charlie
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org