DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22419>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22419 ClasspathResourceLoader should be using the Thread's context ClassLoader ------- Additional Comments From [EMAIL PROTECTED] 2003-09-08 04:47 ------- There's probably some relation, but there's a deeper issue that lies under both bugs: What ClassLoader is used to load resources and classes. I can think of very few instances where the calling thread's preferred classloader shouldn't be used. In my case, for bug 22419, I created a ThreadContextResourceLoader that was identical to ClasspathResourceLoader except for the modification in the patch and the class name. However, in order for this class to be picked up, I had to put it at the system level because when looking for configured resource loaders, Velocity has the same problem: it only tries looking in the classloader it was loaded in (a la getClass().getClassLoader()). In just about any case where a classloader is needed to dynamically load a class or resource, Velocity should still request a classloader from the calling thread (as in the submitted patch). Also, modifying code to use the correct classloader should have no effect on current behavior. If the code that's dynamically loading resources is reachable, then it is at a higher classloader level then the code calling it. If the resource is not found at the lower level, the application server should allow classloading to fall through to higher levels. This patch just fixes ClasspathResourceLoader, which was my primary concern. It would be worth looking for other dynamic class/resource loading code and see if a similar change is necessary. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
