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.