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/deploy (check also inside .sar and .war files)
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
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