It works with a single .EAR. And yes, the domain names are different in each .EAR

How exactly should I debug this? What should I look for? I'm kinda newbie with these classloading issues.

Sorry for the delay. I had to leave work before I could answer you yesterday.

So, the debugging turned out to show something really strange. This piece of code I'm debugging, inside Ejb3Configuration.class:

               Class interceptor = classForName( interceptorName );

                cfg.setInterceptor( (Interceptor) interceptor.newInstance() );

According to the stack trace, I get a ClassCastException in line two. As if my Hibernate interceptor does not implement the "org.hibernate.Interceptor" interface, which it does. Like I said before, I have two EAR's being deployed, and in only one of them I have this custom Interceptor. Here's the output from the debug:

//Ejb3Configuration classloader

this.getClass().getClassLoader()

     (org.jboss.classloader.spi.base.BaseClassLoader) BaseClassLoader@ac97e2{vfsfile:/Users/rodrigouchoa/Java/jboss-5.1.0-dpf.GA/server/default/deploy/corporativo-packaging.ear/}

//My custom interceptor classloader (its different)   

interceptor.getClassLoader()

     (org.jboss.classloader.spi.base.BaseClassLoader) BaseClassLoader@40bd2e{vfsfile:/Users/rodrigouchoa/Java/jboss-5.1.0-dpf.GA/server/default/deploy/sinpi-packaging.ear/}

//The hibernate classloader (same as the first one)      

org.hibernate.Interceptor.class.getClassLoader()

     (org.jboss.classloader.spi.base.BaseClassLoader) BaseClassLoader@ac97e2{vfsfile:/Users/rodrigouchoa/Java/jboss-5.1.0-dpf.GA/server/default/deploy/corporativo-packaging.ear/}

It seems that my custom interceptor is coming from the right classloader, inside the EAR it belongs to. But the Ejb3Configuration.class is running inside the other EAR's classloader! The first and last output are from "corporativo-packaging.ear", and the middle one is from "sinpi-packaging.ear" . How can I isolate these two EARs?

The java2ParentDelegation seems to be working okay. The problem is isolating one EAR from the other.

Different domain name should already separate them.

But it didn't.

Here's the two jboss-classloading files (each inside ear/META-INF)

<?xml version="1.0" encoding="UTF-8"?>

<classloading xmlns="urn:jboss:classloading:1.0"

domain="corporativo.ear"

export-all="NON_EMPTY"

import-all="true"

parent-first="false">

</classloading>

<?xml version="1.0" encoding="UTF-8"?>

<classloading xmlns="urn:jboss:classloading:1.0"

domain="sinpi.ear"

export-all="NON_EMPTY"

import-all="true"

parent-first="false">

</classloading>

The first domain is "corporativo.ear" and the second is "sinpi.ear". Any more clues? Thanks anyway.

Ales,

Doesn't it have something to do with the domain the EJB modules inside each EAR? My custom interceptor is inside its EAR ejb module. Shouldnt it have its own jboss-classloading.xml file?

Ales Justin wrote:

 

I doubt it.

EJBs are probably in your sub-deployment (x.ear/my-ejbs.jar), which belongs to root CL (as one of its roots).

So same rules should apply.

I see.

Does anyone have any ideas?

This happens with all EAR's... We can only deploy one EAR per JBoss 5.1.0.GA AS instance. Everytime two or more of them are deployed at the same time, this type of classloading issues with hibernate libs arise (all EARs have their own hibernate libs inside them, in ear/lib). Unfortunately, we need to update hibernate libs. Is there any other way to achieve the same goal?

Didn't find anything unusual. I turned on the "TRACE" level for org.jboss.classloader.spi.base.BaseClassLoader. It shows hibernate libs being loaded by the two different domains, as it should. The question remains... Why is one EAR using the other EAR's libs when starting up?

If anyone ever come up with any ideas... Please share.