james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anagha Mudigonda <anaghamudigo...@gmail.com>
Subject Re: [jira] Commented: (JAMES-418) Loader uses wrong method to obtain class loader/doesn't set context class loader
Date Tue, 06 Sep 2005 14:41:00 GMT
Stefano,
 I use 
getClass().getClassLoader() in SMTPHandlerChain for loading handler classes 
in load() method.
 Should I replace it with Thread.currentThread().getContextClassLoader()?
  -- Anagha
   

 On 9/6/05, Stefano Bagnara (JIRA) <server-dev@james.apache.org> wrote: 
> 
> [ 
> http://issues.apache.org/jira/browse/JAMES-418?page=comments#action_12322740]
> 
> Stefano Bagnara commented on JAMES-418:
> ---------------------------------------
> 
> The whole classloading issue should be demanded to the container.
> In fact latest phoenix trunk contains code to automatically provide 
> SAR-INF/lib and SAR-INF/classes support to the contained application 
> classloader.
> 
> We can provide a workaround for mailets but the problem should be fixed by 
> using a better container.
> 
> Unfortunately I've not been able to run james in newer phoenix (since 
> phoenix 4.1.0alpha svn16333 to latest trunk)
> 
> 
> > Loader uses wrong method to obtain class loader/doesn't set context 
> class loader
> > 
> --------------------------------------------------------------------------------
> >
> > Key: JAMES-418
> > URL: http://issues.apache.org/jira/browse/JAMES-418
> > Project: James
> > Type: Bug
> > Components: James Core
> > Versions: 2.2.0
> > Reporter: Ben Lindahl
> 
> >
> > I had difficulty loading resources from my classes directory. In 
> reviewing the Loader source code, I see two problems:
> > 1) It uses this.class.getClassLoader(), rather than the 
> preferred/standard Thread.currentThread.getContextClassLoader(). This is 
> not a problem right now, as the Apache James developers have control over 
> the entire application, but could become a difficult bug to track down in 
> the future. In addition, as soon as you start adding multiple class loaders, 
> chaining class loaders with parents becomes impossible (see next point) 
> because it sets the same class loader as multiple parents. In the source 
> code, all instances of this.getClass().getClassLoader() (or 
> whatever.getClass().getClassLoader()) should be replaced by 
> Thread.currentThread().getContextClassLoader()
> > 2) The greater problem is that it does not call Thread.currentThread().setContextClassLoader(classLoader).

> This means that any code that uses the standard method 
> Thread.currentThread().getContextClassLoader() (as my code does) will not 
> get the correct class loader, and thus will not be able to load the 
> appropriate resources. In fact, I was getting the primary class loader, 
> which only loads the Phoenix Jar. I had to add into my code the following 
> (the class loader's parent is already set):
> > Thread.currentThread().setContextClassLoader(
> MyClass.class.getClassLoader());
> > By the nature of Java class loaders, it is expected that the thread's 
> Context ClassLoader is always kept current, and that any new class loaders 
> are added to the chain. I think that this change should be made in the 
> Apache James source code.
> 
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators:
> http://issues.apache.org/jira/secure/Administrators.jspa
> -
> For more information on JIRA, see:
> http://www.atlassian.com/software/jira
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
> 
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message