Problems with re-deployment of a JBoss Interceptor

[solo]

Hi, Sorry for cross posting. I've written a message in the AOP forum but got no replies and I thought it may that it was the wrong forum to pick this subject up.

What I've done is a small demo hack to test some features, It Consists of:

* Interceptor (client and server ala good ol' JBoss) for context passing
* Some AOP interceptors and attributes.
* All is packed into a aopdemo.ear on the following structure:
*** ejb-jar.jar -- EJB stuff only
*** ejb-aop.aop -- AOP interceptors and implementation, JBOSS interceptors

* Everything is pre-instrumented via annotation compiler and aopc.

It deploys ok and I can run testing on the stateless session beans. I change the code slightly and re-deploy the ear. The re-deployment seems to work out ok.

But when invoking the stateless session beans i cannot cast the context payload that gets serialized over the wire to IContext interface. Seems to me like some class loading problem but IContext and interceptor, or rather everything except the bean itself, is in the same jar (ejb-aop.aop). Since *.aop gets deployed with the Aspect manager I wonder if ther's any tweaks done or other that makes this fail?

Many Regards,
Mario

PS.
BTW: If I enable transform to true it will only deploy once, second time
will be a null pointer exception...
DS.


Dump:
----------------------------------------------------------------------------------
19:55:56,917 INFO [STDOUT] (2377175)FATAL: Not a IContext !!!: se.dataductus.aopdemo.context.DefaultContext
19:55:56,917 INFO [STDOUT] Implements: se.dataductus.aopdemo.context.IContext
19:55:56,917 INFO [STDOUT] Implements: java.io.Serializable

[jae77]

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.

[solo]

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?

Regards,
Mario

[jae77]

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.

[solo]

Hi,
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???

Many Regards,
Mario