I need to improve upon my recent commit in order to properly deal with non-serializable exceptions. Andrus has alerted me to the fact that there are exceptions out there (such as one in Derby) which implement Serializable but which have fields which are not serializable.
http://bugs.caucho.com/view.php?id=1796
Seems to me that this is an error in the original implementation (after all, what's the point in implementing serializable if it isn't?), however perhaps we should be tolerant of this type of problem.
It looks like Hessian 3.1.2 will work around the problem and be able to gracefully handle this situation. However Hessian isn't the only possible transport Cayenne might use.
Our options appear to be:1. It isn't our problem. The bug in Derby is going away and Hessian is working around it too. Leave it as it is and put some notes in the docs for people who don't use Hessian. The nice thing is that we can get real exception data onto the client which can be very useful.
2. Add the original exception's stack trace to the CRE message. Simple to do, but slightly ugly in that it fills up the previously concise message with stack trace. Some users may expect their message to be short and sweet.
3. Add new fields to CRE which are guaranteed to serialise (such as String causedByStackTrace and causedByClassName) which can contain this information. But then it is a bit more effort to get them out on the client (say within log4j).
Ari Maniatis --------------------------> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
PGP.sig
Description: This is a digitally signed message part
