On Jun 22, 2010, at 12:19 PM, Paul Sandoz wrote:
>
> 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.
>
Thinking about this further, here is what we could do. Each
WebApplicationException (or subtype) thrown by Jersey could have a
prepared response entity that can be utilized if a certain feature is
enabled. This response entity would be a meaningful String-based error
message to help developers resolve a client issue or contain
information that can be sent to someone to help resolve a server-side
problem.
Paul.
>
>> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>