how are you testing the code, is it from an "outside" client that is connecting to jboss, or do you have some application (ie, a war) that you are using instead?
did you see this wiki page? http://www.jboss.org/wiki/Wiki.jsp?page=HotDeployClassCastExceptions
i'm not sure if there is something different that goes on when using aop, but it may help.
i've also seen instances where i need to restart the server when i've redeployed interceptors that i've written, even though i've "cycled" the classloader appropriately.
Hi and thanks for the quick reply!
No, the test code is running outside the jboss server as a standalone java app. The only code deployed onto the jboss is the ejb and the interceptor, aop stuff.
What do you mean by cycled the classloader, would you mind explaining that?
if you read the wiki page, then if i have A.jar deployed, and A.ear and B.ear depend upon A.jar, if i redeploy A.jar, the class loader is going to have stale references to those classes and give me ClassCastExceptions.
in order to get around that, you "touch" A.ear and B.ear so they are given new class loaders that will re-search for the required classes when a method is invoked.
if you only have one or two packages deployed, this works ok, but if you end up having lots of things deployed and you modify A.jar, you're better off just restarting the whole server.
if you're changing interceptor code, your only option may be to restart the server. your best bet would be to split up the packaging as described in the wiki page (place all the interceptors into the jar, in addition to the ejb home/remote classes and any dependent helper classes) and then try hot-deploying an ear and see if you get issues.
if that works, then try redeploying the jar file and then "touch" the ear so it gets reloaded and see what happens. as a rule of thumb for myself, any time i change interceptor code, i always restart the server to be on the safe side.
Thanks for the "recycle" classloader answer.... :-)
Though my problem is not of that kind. Actually the interceptor will undeployed and re-deployed correctly (with the modifications).
The problem is that everything the interceptor uses are included in the same package ejb-aop.aop. I'm not sure of this but It seems that the re-deployed (new) interceptor uses the old interfaces (from the un-deployed ejb-aop.aop) and the test program uses the newly compiled ones.
But really... I don't get it why it should even complain since I haven't altered the interface and all serializable classes have serialVersionUID attached to them. Anyway it is the interface that do not match.
Is there something here I don't understand.
(A interface do not have a identity such as serialVersionUID or?)
Clearly the serialization mechanism do not complain about serialVersionUID conflicts. And when completely de-serialized the container deployed classes shall be used and thus this should not be of an issiue???