NotSerializableException encountered in EJB3 calling remote service on the server

[mikemil]

We are in the process of testing a migration from EJB 2.1 to EJB 3 on JBoss 4.2.3.GA.   Currently most of our code (inherited from years past) always loads the remote service interface even when we can tell we are on the server.   Not, during testing we are getting a NotSerializableException in places where we load a remote service on the server and make a call.  One instance was us trying to parse some XML and the SAX.parse() method parameters were the XML String and an XML handler.   The handler was the object references in the NotSerializableException.   All of our EJBs are stateless session beans.

I was able to 'get around' this in two ways:

1) load the local interface rather than the remote

2) Changes our XML handler to 'implement Serializable'.

#1 seems like the correct answer, we will just have to digg thru the code and find all these cases where a remote service was called, which then starts making additional service calls.

I wanted to see if someone could verify that this was a change made in the EJB3 area -  because all this code currently works when the beans are EJB 2.1.

[kkkppp]

It's about Jboss 5 but I guess it's the same issue

https://community.jboss.org/message/547133

[mikemil]

Thanks for the quick reply.  I have read thru this and it does seem to match my situation.  I also reviewed JIRA and unfortunately for me, it looks like this was fixed in AS5.1.x (and presumably beyond) but that doesn't help me sitting on JBoss 4.2.3.  I posted a comment on one of the Jira entries asking for clarification but I sure looks like nothing in 4.2.3.

Thanks again!

[mikemil]

I've been doing some more testing and I swear it appears as thru JBoss 4.2.3 is handling SOME of the cases where a remote proxy is retrieved and we want to run locally.  It seems like the couple cases we have seen may have been triggered on the server thru JMS rather than a client making a remote call.   I have debugged client and server code and seen the proxy class returned as StatelessRemoteProxy and yet still works locally without having to get the local interface rather than the remote.

Don't get me wrong, this is a GOOD thing - except I need to know how to identify the specific cases that may fail!