ClassCastException within an EAR deployment

[heizenberg]

DVS3.ear/
 +-Util.jar (J2EE utility project)
 | +-dvs3.Changelist (java interface)
 |
 +-Core.jar/ (EJB Project)
 | +dvs3.code.session.ChangelistService (java interface that extends dvs3.Changelist)
 | +dvs3.code.session.ChangelistServiceBean (stlss sess bean that implements ChangelistService)
 |
 +-WebUI.war/
 | +dvs3.code.action.JSFBackingBean (a bbean that calls a session bean service via JNDI)

I'm assuming the manifest files are defined correctly since both Core.jar and Util.jar are referenced in the WebUI.war manifest file and Util.jar is referenced in the Core.jar manifest file.

In the backing bean, I have this piece of code:

String jndi = "DVS3EAR/ChangelistServiceBean/local";
 Object service = new InitialContext().lookup(jndi);
 System.out.println(service instanceof ChangelistService) // prints true
 System.out.println(service instanceof Changelist) // prints false
 Changelist service = (Changelist) obj; // fails with a ClassCastException

Why is this?

At some level, isn't this violating a fundamental java principle? Since ChangelistService is a Changelist, why can't I cast the service object to be a Changelist, but can cast it to be of type ChangelistService?

Is this some kind of weird (but legal) classloading?

[jaikiran]

See these:

http://wiki.jboss.org/wiki/Wiki.jsp?page=ClassCastExceptions

http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossClassLoadingUseCases

http://wiki.jboss.org/wiki/Wiki.jsp?page=ClassLoadingConfiguration

[ejb3workshop]

Maybe have a look at the EJB3 specification Section EE 8.2. It describes the mechanism for packaging utility classes within EAR files.

[heizenberg]

I doubt if it's EAR packaging. If I had a ClassNotFoundException, that would have been my first guess. I can see the classes... I just cannot seem to class it to the base interface. Perhaps one of the documents pointed out by JaiKiran holds a clue or two, but I haven't found them so far.

[heizenberg]

I meant 'cast' and not 'class' in my last reply above.

[jaikiran]

There's a jmx-console method mentioned at http://wiki.jboss.org/wiki/Wiki.jsp?page=ClassCastExceptions. See if that's of any help.

[heizenberg]

Thanks JaiKiran. I did check my class loaders in my JMX console. It showed no duplicates. I also tried playing with a jboss-app.xml file and tried to specify one classloader for the entire EAR. That didn't help either.

[jaikiran]

Let's try another approach then. When you start JBoss through run.bat (or run.sh) pass the -verbose:class JVM parameter. Like this(for run.bat):

set JAVA_OPTS=%JAVA_OPTS% -Xms128m -Xmx512m -XX:MaxPermSize=256m -verbose:class

Then start JBoss. This will print out to STDOUT the classes being loaded and also the jar files being used for loading these classes. I would recommend redirecting the STDOUT output to some file, as the logs will be too huge:

run.bat > classes_out.log

Access your application to get the ClassCastException. The classes_out.log will contain the appropriate information about which jar is being used for loading the Changelist* classes (just do a text search in that log file for this class).

[heizenberg]

I just saw what the problem is, even though I thought I already looked before.

The J2EE utility project I've deployed had the same libraries selected in both the tabs (J2EE Modules and Web Libraries) of the J2EE Module Dependencies settings (on Windows... this doesn't seem to happen on the Linux version of RHDS).

On looking at the deployment, it seems like every time I deploy the EAR, it copies the top level J2EE Utility project libraries into the root level of the EAR and ALSO into the lib folder of my WAR. It doesn't do this in Linux. In Windows, every time I unselect the utility projects in the Web Libraries tab, it comes back when I check the project options again. The only time this has worked, is when I went in and hit the 'Deselect All' button.

So the classloader issue has been straightened out for me, and I should report this as a RHDS bug.