Hi Poul,
I don't like these two options. I actually prefer to get the exception in the response just like what you f.x. can get in Java or .NET web apps when an errors. Why should REST WS different ? Also, I like to be able to use a normal browser to navigate a (HATEOS-complient) REST WS and for a browser to show the error by default we need the error info in the response.
P.S. I have recently experimented by create a jersey client filter that extracts a stack trace from the response entity if present and rethrow it. That works fine, except that I would have liked to have access to what response object the client wants returned so I can decide between throwing or logging the exception depending on the status and response object that the client want.
/Morten
--- Den tirs 22/6/10 skrev Paul Sandoz <Paul.Sandoz_at_Sun.COM>:
> Fra: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
> Emne: [Jersey] Debugging Jersey apps: idea for obtaining exceptions
> Til: "users_at_jersey.dev.java.net List" <users_at_jersey.dev.java.net>
> Dato: tirsdag 22. juni 2010 18.12
> Hi,
>
> One issue is when Jersey throws exceptions that are mapped
> to responses, while some of the information is often logged
> in the server log, it is often hard to correlate that with
> the client as the exception appears to be swallowed.
>
> We don't what to place the exception information as a
> response entity as that could interfere with what the client
> wants to do.
>
> Here are two possible options, when in a "debug" mode e.g.
> when tracing is on:
>
> 1) send the exception stack trace as a response header,
> this could be rather large and might cause some clients to
> barf,
>
> 2) send a response header with a URL to where the exception
> stack trace may be obtained. For this we can keep a little
> in-memory resource that holds the information about the
> request and the exception and it can occasionally flush it's
> state.
>
> Note that we are also considering what is termed a probe in
> GlassFish so that in a running system one can dynamically
> instrument it and then obtain such exceptions and
> correlate to a request.
>
> Thoughts?
>
> Paul.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>