The only information that i could get out of that stacktrace was that a sar was being deployed when this exception is thrown. Can you give us more details about how your MDBs are packaged and where have you created the queue?
Can you give us more details about how your MDBs are packaged and where have you created the queue?
What we have is (fairly) straighforward - a jobcontrol.ear file that contains the following:
foo.jar - The core classes of our app.
jobcontrol-ws.war - A web service interface for our app.
jobcontrol-mdb.jar - The MDB that acts as an interface between the web service and the core classes. It responds to messages posted by the web service.
At present jobcontrol-ws.war and jobcontrol-mdb.jar have some classes in common, which are themselves in common with the classes of foo.jar. This is not optimal but shouldn't be affecting our deployment right now, as far as I know.
The EAR file also contains a bunch of libraries in jars, and the container on the server has a bunch more in its lib/ directory. None of these overlap, as far as I know. foo.jar, jobcontrol-ws.war, and jobcontrol-mdb do not have any libraries in them.
The queue is created by the app server - the configuration in the EJB creates it, as can be seen at http://pastie.caboo.se/40508.
For the sake of those who may come across this in the search for their own solutions, I thought I should report back about the cause of this error.
We had a couple of issues on the go, as it turns out: one thing that wasn't helping was our JBoss machine had run out of disk space. However, the main problem was that we had inadvertently included a jndi.properties file in our EAR deployment. I'm not familiar with the configuration in this file, but it was sufficient to completely hose our messaging in the manner described above. Removing it from our EAR solved the ClassCastException.