JBoss Community

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.

JBoss provides a way to find these duplicate deployments.

Go to the JMX console for JMImplementation:service=LoaderRepository,name=Default

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

Invoke displayClassInfo with the name of the class

Example:  for javax.management.ObjectName:

++++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