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
This archive was generated by hypermail 2.0.0 : Sat Jul 14 2007 - 16:44:18 EDT