"worenk" wrote : | 1) We are using several 3rd party libs that the JBoss container itself is using another version of (in server/default/lib). We'd prefer if JBoss libraries would not be visible to our applications, so we can use our own versions. Is this possible? | I'm pretty you can't override system level dependencies. For example, when JBoss starts, the root classpath with have everything in $JBOSS_HOME/lib such as dom4j. If you want to use let's say XPath, i.e. jaxen.jar, you need to add that dependency in lib if you want it accessible. You can turn off JavaToParent delegation via a JBoss XML parameter (forgot what it was but look up ClassLoading in the WIKI Knowledge Base under the application server portal page) which may get around it, not sure. Its a shame classloading is so obscure in the spec. anonymous wrote : | 2) Our EJB-client-classes are traditionally contained in both the WAR and our EJBs. Because there is no clear classloader separation between J2EE modules in JBoss, the classloader has troubles loading those (shared) classes, unless I exclude them from the WAR (which is client of our EJB). Is it possible to switch on clear classloader separation for J2EE modules, too? | Andreas, its good practice to not have the same classes laying around in different deployable entities (because to the classloader they will BE DIFFERENT classes causing all kinds of havoc). What you SHOULD DO is turn on EAR isolation/call by value during JBoss install (or edit the deployer.xml file afterward) so EARs are at least scoped. Besides being scoped, you can use JBoss specific parameters to setup a classloader repository per EAR (though if they are scoped, I'm not sure why this is neccessary). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3966540#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...