I had a check using the instructions on this page, and it basically follows the same steps as mine. The critical difference is apparently in the contents of its jboss-app.xml :
<jboss-app> <loader-repository> org.myapp:loader=SomeClassloader <loader-repository-config> java2ParentDelegation=false </loader-repository-config> </loader-repository> </jboss-app>
My system does not disable parent delegation, it only has a bootloader name:
<jboss-app> <loader-repository>org.myapp:loader=MyAppName</loader-repository> </jboss-app>
You can (or cannot) also set the Isolated = true attribute in the JBoss deploy/ear-deployer.xml :
And it works well. By disabling parent delegation, you are impairing the ability of your application to interact with the container in any way, which is a bit extreme. If you do not consider this option, yak shaving is required .
If you leave the java2ParentDelegation=false parameter, you get a situation where any classes in the EAR that have the same name as the classes in JBoss will be loaded mainly from the EAR (which is good). However, any classes not found in the EAR will fall into JBoss libs. In the case of jboss-local-jdbc.rar this is good. However, it can have special side effects.
For example, when Hibernate creates a factory session, it searches for the Hibernate Search and Hibernate Validator libraries and tries to start them. If they are not in your EAR, they will find them in JBoss libs. The problem is that you often get a linker error, because the versions of Search and Validator that come with JBoss may not be compatible with Hibernate packaged in your EAR.
The solution to this is either to set up a Hibernate factory session to disable the registration of Search and Validator listeners using the configuration properties ( hibernate.validator.autoregister_listeners=false and hibernate.search.autoregister_listeners=false ), or to pack compatible versions of Search and Validator in your EAR as well .