ClassCastExceptions

If casting an argument to its expected type fails, then likely two instances of the same class were loaded in two different deployments.  If you're not careful with isolating or sharing classes, this will happen.  The paths to check:

 

  • $JBOSS_HOME/server/default/lib

  • $JBOSS_HOME/server/default/deploy (check also inside .sar and .war files)

  • $JBOSS_HOME/lib

  • Your system or boot classpath

 

Depending on how unlucky you may be, you might get a LinkageError or ClassCircularityError as well.

 

Earlier versions of JBoss provides a way to find these duplicate deployments (displayInfoForClass() was removed from 3.0.x - https://jira.jboss.org/jira/browse/JBAS-3180):

 

Go to the JMX console for

 

http://localhost:8080/jmx-console/HtmlAdaptor?action=inspectMBean&name=JMImplementation%3Aservice%3DLoaderRepository%2Cname%3DDefault

 

Invoke  with the name of the class

 

Example:  for :

 

++++CodeSource: (file:/tmp/servers/jboss-3.2.6/lib/jboss-jmx.jar )

### Instance0 via UCL: org.jboss.system.server.NoAnnotationURLClassLoader@119298d

 

If you see multiple "Instance1" and multiple CodeSources then this could be the cause of the ClassCastExceptions that you are seeing.

 

Try to isolate the classes in these deployments by following the instructions given in the Class Loading Overview wiki page (link at the bottom of the page).

 

-


This is also the standard situation when you are trying to lookup/cast your EJB3 bean and get the ClassCastException. This often happens when you have ear1.ear with your EJB beans and ear2.ear or webapp.war deployed into the same server with CLIENT STUBS.

 

Please note that client stubs are useful ONLY in the case of remote deployment. When using local interfaces do the following:

 

1. REMOVE client stubs from ear2.ear/webapp.war/whatever

2. Configure the same loader repository for both ear1.ear and ear2.ear/webapp.war

 

Related

ClassLoadingOverview