I have a stateless session bean that I'd like to make available to a number of war applications.
I'd like to (occasionally) update that session bean and have the changes be immediately made available to those war applications. But it seems that no matter what I do, the redeploying of the session bean results in ClassCastExceptions being encountered when the web applications look up the session bean's interface. These exceptions persist until either the server is stopped/started or the war file is redeployed. My best guess is that there's a disconnect between the Tomcat and JBoss class cache... the EJB is undeployed from JBoss and JBoss clears it's cache. Then the EJB comes back, JBoss loads those classes, and is ready to go. But Tomcat still has a reference to the old class files, and thus when it does its JBoss lookup of the EJB's interface it gets what appears to be a "different" class than what it has cached (even though nothing in the interface has changed) and dies. ...is that a (somewhat) accurate description of what's happening? If so, is there some way to avoid the class conflict? A serialVersionUID seems like it would be a slick solution, but of course those can't be placed on interfaces. Another (crude) solution would be to catch the ClassCastException, somehow tell Tomcat to flush it's cache for that particular context, then try the lookup again... but perhaps there's a more standard solution out there...? Thanks in advance, - Nathan View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4090465#4090465 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4090465 _______________________________________________ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
