"oskar.carlstedt" wrote : Deploying the same file again, but without the jars log4j and commons-logging. Wolla!!, It seems to work. | | Isn't this a classloader bug/error? What I mean is. The files I put in my ear are those I want to use, especially in isolated mode. It shall not matter if a put a log4j jar in my ear, it shall override the one in the server/default/lib folder. | | I think this is very important when delivering ready to install archives (an archive I can send to a customer just telling him "drop the ear in the deploy folder and that's it"). | | //Oskar | No I don't its a bug per se but a JBoss behavior/choice. Java works on class loader parent delegation so if the jar is already in server/default/lib, it will pick that one up FIRST before it loads yours. Your manifest entries just put these classes on the path for the loader to find them. However, again, classloader is going to look at the parent loader which will contain log4j and pick that one first before it even attempts to load the one you package. Now, I TOTALLY agree with you that there should be a way to get around this on a per EAR level but I don't think thats covered by the spec at this point (and yes I voiced this opinion to the group at one point a while ago). I noticed that unlike 4.0.4.GA, 4.0.5 finally puts back jaxen which was something we had to manually do to get access to XPath. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4029531#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...