|
If you were logged in you would be able to see more operations.
|
|
|
| Resolution Date: |
25/Sep/06 12:13 AM
|
|
Occasionally Application or System exceptions thrown to a client hold data which is not serializable and prevents the exception from being serialized. This prevents the exception from reaching the client.
The second and most common scenario is that the exception class is not on the client side and deserialization fails as the class cannot be loaded.
The ejbd server protocol could be updated with improved serialization logic on system and application exceptions. 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.
The tricky part is that it is a little hard to make an identically looking exception instance to throw the client.
|
|
Description
|
Occasionally Application or System exceptions thrown to a client hold data which is not serializable and prevents the exception from being serialized. This prevents the exception from reaching the client.
The second and most common scenario is that the exception class is not on the client side and deserialization fails as the class cannot be loaded.
The ejbd server protocol could be updated with improved serialization logic on system and application exceptions. 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.
The tricky part is that it is a little hard to make an identically looking exception instance to throw the client.
|
Show » |
| There are no subversion log entries for this issue yet.
|
|
Improvement
Closed
Minor
Support for common Exceptions serialization issues
