On Jul 13, 2007, at 4:56 AM, Aristedes Maniatis wrote:
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.
While I don't think it will be always safe to rely on all drivers to
provide fully serializable exceptions, I thought of another, more
important reason why it won't work - client may not (and should not)
have all server classes in its CLASSPATH and therefore will not be
able to de-serialize many of the exception classes.
Theoretically any server component can throw a runtime exception.
JDBC driver and server-side callback methods are the two most likely
cases. You probably don't want to keep all server jar baggage on the
client - that kind of kills all the ROP appeal.
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).
Maybe we can build upon #3:
4. Subclass a CRE, creating a special exception thrown by the
service, that has an extra field storing a String representation of
the cause stack trace.
Andrus
