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.
Or will the returned URL parse the log for me and display the
appropriate information?
>
> 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.
A+
-- Jeanfrancois
>
> 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
>
>