Grokbase Groups Cayenne dev July 2007
FAQ
In ROP, we only get CayenneRuntimeExceptions (CRE) returned to the
client. This hides much of the cause of the original problem from a
user debugging problems at the client end since the stack trace of
the original exception is lost and all you get are the details of the
CRE itself thrown by BaseRemoteService at around line 175.


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.
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

Search Discussions

  • Andrus Adamchik at Jul 14, 2007 at 8:44 pm

    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
  • Marek Wawrzyczny at Jul 16, 2007 at 5:16 am

    On Sun, 15 Jul 2007 06:43:53 Andrus Adamchik wrote:
    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

    Hi,

    Long time lurker seldom poster :)

    Could another option be to provide server side hooks at the point where a CRE
    is propagated to the client which allows the programmer to report the
    exception server side?
    This way, an exception can be send to the client as it is being sent now,
    however the true stack trace could be saved to a log file or emailed (for
    example) by custom server-side code.

    Marek
  • Andrus Adamchik at Jul 16, 2007 at 8:02 am

    On Jul 16, 2007, at 8:16 AM, Marek Wawrzyczny wrote:

    Could another option be to provide server side hooks at the point
    where a CRE
    is propagated to the client which allows the programmer to report the
    exception server side?
    This way, an exception can be send to the client as it is being
    sent now,
    however the true stack trace could be saved to a log file or
    emailed (for
    example) by custom server-side code.
    +1.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdev @
categoriescayenne
postedJul 13, '07 at 1:57a
activeJul 16, '07 at 8:02a
posts4
users3
websitecayenne.apache.org

People

Translate

site design / logo © 2022 Grokbase