ClassLoader rule-of-thumb? (Re: DefaultLogTargetFactoryManager)

[Jeff Turner <je...@socialchange.net.au>]

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?

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?

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?

I am woefully ignorant of classloaders, so any explanations appreciated
:) Otherwise, a rule of thumb would do just fine.


--Jeff

> /LS

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: ClassLoader rule-of-thumb? (Re: DefaultLogTargetFactoryManager)

[Peter Donald <pe...@apache.org>]

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: ClassLoader rule-of-thumb? (Re: DefaultLogTargetFactoryManager)

[Leo Sutic <le...@inspireinfrastructure.com>]

> -----Original Message-----
> From: Jeff Turner [mailto:jeff@socialchange.net.au]
> Sent: den 22 november 2001 12:31
> To: Avalon Developers List
> Subject: ClassLoader rule-of-thumb? (Re: DefaultLogTargetFactoryManager)
> 
> 
> 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?

Yes. See http://www.javageeks.com/Papers/ClassForName/index.html for why.

/LS


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>