On Thu, 22 Nov 2001 22:31, Jeff Turner wrote: > Hi Leo, > > On Thu, Nov 22, 2001 at 09:40:09AM +0100, Leo Sutic wrote: > > Line 86: > > logTargetFactory = > > (LogTargetFactory) > > this.getClass().getClassLoader().loadClass( factoryClass ).newInstance(); > > > > This leads to some classloader issues. Is there a reason for this or can > > the context class loader be used instead? > > If I may take the opportunity to ask.. is the general rule that one > should prefer the context classloader to that of the code's class?
Depends on where you expect the code to be run. If you expect your code to run in some sort of container (ie servlet, ejb, phoenix, whatever) then it is expected that the container will setup ContextClassLoader correctly. In a container context there is no guarentee that the loader used for current class come from any particular hierarchy. Thats why servlets and EJBs can intermix their ClassLoaders somewhat promiscuosly and apps still run (because they use the ContextClassLoader). If your are not running in a container then there is no hard and fast rules but most environments would expect that Class.forName() (which uses the caller classloader) or getClass().getClassLoader().loadClass() to work. > Ie, Thread.currentThread().getContextClassLoader() instead of > this.getClass().getClassLoader()? > > I notice that Cocoon2's ClassUtils always returns the context CL. I'm > guessing that the context CL is more flexible, because the caller may > belong to a less "primitive" classloader than the excalibur code. Does > that sound right? That works because in most cases people are probably using Cocoon2 in a servlet. It would be nicer if Cocoon2 did not rely on ContextClassLoader and loaded from getClass().getClassLoader() if ContextClassLoader was not set. > Eg, say that avalon-excalibur.jar is in Tomcat 3.2's $TOMCAT_HOME/lib. > Your class in WEB-INF/lib tries to set the factory class mentioned above > to something else in WEB-INF/lib, then the context CL will work, and the > class CL will fail? correct. Though webapp classloaders slightly violate the normal ClassLoader rules, as of 2.3 it is recomended that they search the local repositories before searching parent classloaders os if you also had excalibur in you WEB-INF/lib then it would work .... at least on some containers who follow recomendation ;) -- Cheers, Pete *------------------------------------------------* | Trying is the first step to failure. | | So never try, Lisa - Homer Jay Simpson | *------------------------------------------------* -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
