[ http://issues.apache.org/jira/browse/JAMES-418?page=comments#action_12361380 ]
Stefano Bagnara commented on JAMES-418: --------------------------------------- Ok, but I think that in case Peter or anyone else will not apply the tag we should upgrade anyway, either by using the SVN revision or by committing the phoenix sources to the james repository for reference so we can tag them and we exactly know what is the distributed container. IMHO a tag on a repository that has not been touched in the last 2 years shouldn't be so important for our release cycle. We need to have a fixed 2.3.0 release and the current option is to upgrade to phoenix-trunk or to loom. Phoenix trunk (after a fix in the cornersone-datasources-impl) seems to work fine, loom has an incompatability interpreting the spaces in the config.xml file. Furthermore You and Peter, if I understood correctly, said that phoenix-trunk is preferred to loom. So if noone has a better option to fix this issue we should avoid further "show stoppers". > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
