In the checkin Fri Nov 24 jboss/src/main/org/jboss/deployment/J2eeDeployer.java v1.12 jboss/src/main/org/jboss/deployment/Installer.java v1.1 there are a couple of changes that introduce a deployment bug. 1. J2eeDeployer.startApplication() ~line 400 We now start the .war files first, then the .jar files Before starting the .jar files, we set the context classloader to be the server classloader, not the application classloader. This means that common libs in the application classpath are not seen by the ejb jars, forcing the deployer to put common libs into the SERVER classpath. Unfortuanately, we cannot work around by setting the context classloader to be the application classloader, because of this: 2. Installer.execute() ~line 310 add all ejb jar files to the application common classpath because the application classpath contains ALL the ejb-jars, if we set the application classloader to be the parent of the container classloader, then when we go to load META-INF/jaws.xml, it is loaded by the application classloader (possibly from the wrong ejb jar) rather than by the container classloader. Proposed Fix: Dont put ejb jars in the common classpath! (ie remove lines I dont see why it makes sense for the application classloader to see all of the ejb jars. I see that as the distinction between ejb jars and shared jars - if I want something shared I will put it in a shared jar. That was the behavior in 2.0 final, and it worked fine. Alternative - could create a new classloader for loading META-INF/jaws.xml.
