On Jun 22, 2010, at 9:29 AM, Jeanfrancois Arcand wrote:
> Salut,
>
> On 10-06-22 12:12 PM, Paul Sandoz wrote:
>> 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.
>
> I don't recall if Jersey is already doing that, but would it help to
> log the exception with a unique token and send back that token as a
> header? This way you can always correlate the token with the
> exception in the log.
>
That is a good idea, even if tracing is not enabled. However, by
default when an exception is mapped to a response using an exception
mapper the exception is not logged. The logic being the application
manages things so no logging is required. Only a
WebApplicationException with a status code of 500 and no response
entity is logged i.e. this signals that something has gone wrong with
the server side.
> Or will the returned URL parse the log for me and display the
> appropriate information?
>
Kind of. I was thinking of storing the information in memory rather
than accessing the server.log (not actually sure if i can access the
server log in any meaningful semantic way?)
Paul.