"[EMAIL PROTECTED]" wrote : | Who has some mess? | | Thread.currentThread().getContextClassLoader().loadClass() not Class.forName()
I disagree, when I do an import org.domain.SomeObject (and use it) it will be loaded by the currentClassLoader, not by the contextClassLoader. So in effect jdom uses saxpath as an import / hard depency. Nothing wrong with that. IMHO the forest of UCLs is the problem. (or is that a flock? :-) ) Of one thing I'm sure: jBoss should not expose jdom.jar to deployed applications. Don't get me wrong I like the UCL forest. Ah I think I'm beginning to see the start of the tunnel: - A.ear gets deployed - B.ear wants to use interfaces - either via same class loader to avoid class cast ex, or through marshalling which is slow thus JBoss puts it all on one heap / loader repository. The last part is not the way I preffer it. What if: - A.ear gets deployed - B.ear gets deployed both with hierarchical repositories which can access children. Then A would load from (in order of priority) (very much simplified): - server/test/deploy/A.ear/lib - server/test/lib (parent) - server/test/deploy/B.ear (siblings of parent) - lib (parent) - server/other/lib (siblings of parent) This way jdom will get exposed but at a very late stage. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3839077#3839077 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3839077 ------------------------------------------------------- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
