I am having the same problem. I've seen this discussion all over the place dating back to 2002. My understanding is that there is no bug in jboss, it's just the way it is. However, I'd love to see a discussion of a workaround. The only one I've seen is to bundle everything in the same ear. In our situation, this is not possible. We have a server app which exposes our bean, and we want our customers to be able to create their own clients of it. There is no way we are going to get their apps in our ear. We need to be able to hot deploy our application and not have all the clients get a subsequent ClassCastException when doing a jndi lookup of our bean. Is the solution to redeploy all the clients after the server app with our bean is redeployed? I obviously can catch the exception, but I'm wondering what do I do about it once it's caught. Is there any way I can recover in my client app once I get this CastClassException when doing the jndi lookup? Can I force a reload of something so that I don't have to restart the client? Here's the diff of the JNDIView output of the relevant bean in our situation. Proxy90 is before the hot deploy of our server app and bean. Proxy145 is from after. Thanks for any and all help. < | +- local (proxy: $Proxy90 implements interface com.perimeter.anyswitch.IAnySwitchLocal,interface org.jboss.ejb3.JBossProxy,interface javax.ejb.EJBLocalObject) | | --- | | > | +- local (proxy: $Proxy145 implements interface com.perimeter.anyswitch.IAnySwitchLocal,interface org.jboss.ejb3.JBossProxy,interface javax.ejb.EJBLocalObject) | | | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4162257#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...