On Jun 22, 2010, at 11:43 AM, Morten wrote:
> 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.
>
That is application specific behavior. Not all applications want to
provide that information in the response entity e.g. some consider a
stack trace as exposing information that is a security risk, or
meaningless because the human cannot understand it (e.g. does Granny
understand a Java stack trace?).
So we can provide a feature we can turn on for that, but i do not
think we can have that on by default.
> 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.
>
You should be able access the Accept header on the ContainerRequest.
Also Jersey sets a Throwable that was mapped from a Response on the
ContainerResponse.
Paul.
> /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
>>
>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>