David Blevins wrote:
IMHO, neither. I've been meaning to add functionality to the server that deals with all sorts of issues we've had with serializing exceptions. More often than things not serializing are things not deserializing because a required class is not present in the client vm.
That's another story I don't want to tackle with yet. Not at the moment where I'm going to fix the PetStore issue, which I had to delay becuase of a problem with a CMP to which I'm creating a itest case. If I had to add yet another factor to sort out before tackling with the real issue I'd probably never get back to the point I had started from. Definitely, it's not that time.
One of the basic concepts I've thought is to basically wrap the exeption and a string version of the exception in an externalizable object and write that to the stream. A failure to serialize/deserialize something inside an externalizable object doesn't cause the stream to become corrupted as the externalizable object itself is written in it's own special buffer by the ObjectOutputStream. So you would write (or read) the string version first, then make an honest attempt to write (or read) the actual excption instance.
Where should I take a look at? I'd like to write it down as a JIRA issue and attach your comment to it.
Now all that is beautiful, except that it is a little hard to make an identically looking exception instance to throw the client.
I think the above question about some more explanation would give me more insight on what you're talking about (which I don't fully understand at the moment).
If I remember from the test case uses SQLException as an application exception.
Correct. Should it throw SQLExceptions which in my opinion are of no value to a client? I think the bean itself should catch it and throw your own designed application exception, but...
I don't think we really need a flag for something like this as I can't imagine a scenario where people would want the behavior we have now if there was something better.
Well, the scenario would be when a deployer have to deal with exceptions , which are of no value to the client, but are thrown by EJBs and aren't serializable. I think it has a tremendous impact on the performance where the unnecessary exceptions (that cause the NoSerializableExceptions) are sent back to a client which in fact disregards them. How to avoid sending them?
I remember a configuration parameter of BEA WebLogic Server that turns off exceptions so that they aren't sent back to EJB clients.
-David
Jacek
