[prev in list] [next in list] [prev in thread] [next in thread] 

List:       james-dev
Subject:    [jira] Updated: (JAMES-418) Loader uses wrong method to obtain class loader/doesn't set context clas
From:       "Stefano Bagnara (JIRA)" <server-dev () james ! apache ! org>
Date:       2005-12-28 19:57:03
Message-ID: 1036027810.1135799823468.JavaMail.jira () ajax ! apache ! org
[Download RAW message or body]

     [ http://issues.apache.org/jira/browse/JAMES-418?page=all ]

Stefano Bagnara updated JAMES-418:
----------------------------------

    Attachment: phoenix-trunk.zip
                cornerstone-datasources-impl-2.1.jar

Here are the phoenix-trunk provided by peter royal, upgraded to the latest \
cornerstone/excalibur and a patched cornerstone-datasources-impl to make it running. \
Without the patch it does not start due to validation errors in the \
database-connections of the config.xml

> 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
> Assignee: Stefano Bagnara
> Attachments: cornerstone-datasources-impl-2.1.jar, phoenix-trunk.zip
> 
> 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


[prev in list] [next in list] [prev in thread] [next in thread]