JBoss Scoped Class Loading

Question

I want to use the latest hibernate version inside the ear without upgrading the jars on the server. I am following the instructions given here - http://jaitechwriteups.blogspot.com/2008/08/how-to-upgrade-hibernate-in-jboss.html.

However the problem now is the application is not taking the jboss-local-jdbc.rar sitting in the deploy folder.

2009-07-21 09:01:50,347 INFO  [org.jboss.system.ServiceConfigurator] Problem configuring service jboss.jca:service=DataSourceBinding,name=MockDS
org.jboss.deployment.DeploymentException: Exception setting attribute ConnectionManager = jboss.jca:service=LocalTxCM,name=MockDS on mbean jboss.jca:service=DataSourceBinding,name=MockDS; - nested throwable: (javax.management.InvalidAttributeValueException: Set attribute  has class class javax.management.ObjectName loaded from null that is not assignable to attribute class class javax.management.ObjectName loaded from org.jboss.mx.loading.UnifiedClassLoader3@1babddb{ url=file:/C:/servers/jboss-4.2.2.GA/server/default/tmp/deploy/tmp22267hibernate_upgrade_test.ear ,addedOrder=43})
    at org.jboss.system.ServiceConfigurator.setAttribute(ServiceConfigurator.java:707)
    at org.jboss.system.ServiceConfigurator.configure(ServiceConfigurator.java:382)
    at org.jboss.system.ServiceConfigurator.internalInstall(ServiceConfigurator.java:462)
    at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java:171)
    at org.jboss.system.ServiceController.install(ServiceController.java:226)
    at sun.reflect.GeneratedMethodAccessor23.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

Any idea ?

Answer 1

I had a scan through the instructions on that page, and it mostly follows the same steps that I have. The critical difference seems to be in the contents of his jboss-app.xml file:

<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 the loader name:

<jboss-app>
 <loader-repository>org.myapp:loader=MyAppName</loader-repository> 
</jboss-app>

You may (or may not) also need to set the Isolated=true attribute in JBoss's deploy/ear-deployer.xml file:

And that works nicely. By disabling parent delegation, you cripple your application's ability to interact with the container in any way, which is a bit extreme. If you leave out that option, though, a bit of yak shaving is required

By leaving out the java2ParentDelegation=false option, you get a situation where any classes in your EAR which have the same name as classes in JBoss will be loaded preferentially from the EAR (which is good). However, any classes not found in the EAR will fall through to JBoss's libs. In the case of jboss-local-jdbc.rar, this is good. However, it can have peculiar side effects.

For example, when Hibernate creates a session factory, it looks for the Hibernate Search and Hibernate Validator libraries, and tries to start them up also. If these aren't present in your EAR, it will find them in JBoss's libs. The problem is that you often then get a linker error, because the versions of Search and Validator shipped with JBoss may not be compatible with the Hibernate packaged in your EAR.

The solution to this is to either configure the Hibernate session factory to disable registration of Search and Validator listeners using config properties (hibernate.validator.autoregister_listeners=false and hibernate.search.autoregister_listeners=false), or to package compatible versions of Search and Validator in your EAR also.

Answer 2

I'm using the jboss-classloading.xml file which is dedicated to classloading. The syntax is more natural than the jboss-app.xml syntax to me. See http://phytodata.wordpress.com/2010/10/21/demystifying-the-jboss5-jboss-classloading-xml-file/ for a comprehensive explanation.

Answer 3

Jerrish,

You seem to be packaging a jar containing javax.management.* classes within your application packaging. Remove that jar from the application packaging (since it already ships in JBoss AS).

Answer 4

Why don't you just remove the hibernate jars on the jboss application server?