Web layer exception handling

[jri]

A plugin should be able to throw a WebApplicationException? to produce a specific HTTP error response. Currently this is not possible in every situation because the Webservice module catches all exceptions and wraps them in a generic WebApplicationException? (which always produce a 500 response).

So far this wrapping is there just to workaround a logging issue: exceptions which are not handled by Jersey are passed on to Jetty (the servlet container). Then both, Jersey and Jetty log the exception yielding to the exception logged twice. And because Jersey and Jetty execute in different threads the respective stack traces intersperse each other and renders the exception log nearly unreadable. The wrapping workaround fights that situation by avoiding exceptions to be passed to Jetty but at the same time it hinders plugins to produce specific HTTP error responses.

Subject of this ticket:

• Stop the Webservice module from wrapping all exceptions in generic WebApplicationExceptions?.
• Provide a JAX-RS exception mapper that re-throws WebApplicationExceptions? directly and wraps all other exceptions. Thus no exception reaches Jetty anymore.

This solves the problem of interspersed logging. At the same time this allows plugins to produce specific HTTP error responses.

[jri]

Revise web layer exception handling (#484).

The proliferation of WebApplicationExceptions? is limited: resource methods and event handlers only throw a WebApplicationException? when a specific response status needs to be sent.

The problem of interspersed illegible stack traces is solved by introducing a JAX-RS exception mapper.

PLUGIN DEVELOPER NOTE:
To send a specific response status throw a WebApplicationException? from your resource methods or event handlers. The WebApplicationException?'s status code will be send back to the client. In the other cases throwing a RuntimeException? is sufficient. Wrapping a RuntimeException? in a WebApplicationException? is no longer required.

See #484.

Changeset: ae57394830c64ce8bf218d2eb10bedc961469122

[jri]

Access Control: fix exception log (#474, #484).

Exceptions thrown by the Access Control's request filter are not logged twice on the console.
If file logging is activated all excpetions are logged properly.
Generally, since the Servlet Filter is dropped (see #448) exception handling is more straight forward.

Exceptions thrown by resource methods and event listeners are logged more clearly.

Close #474.
Close #484.

Changeset: 2b587af7e68b50d8ca45697fb3a6a129d92585fb

[jri]

The JAX-RS Exception Mapper should handle Errors as well (not just RuntimeExceptions?).
Currently an illegible interspersed exception log still appears when e.g. a NoClassDefFoundError? is thrown.

[Jörg Richter]

Webservice: errors are mapped as well (#484).

The JAX-RS Exception Mapper maps errors as well (not just RuntimeExceptions?).
Thus the exception log is still readable when e.g. a NoClassDefFoundError? occurred.

The provider class is renamed:

RuntimeExceptionMapper -> CatchAllExceptionMapper

Close #484.

• Changeset: 8f6262f08b0855d4645fa82008aa22b432572a10
• URL: ​https://github.com/jri/deepamehta/commit/8f6262f08b0855d4645fa82008aa22b432572a10

[Jörg Richter]

Webservice: errors are mapped as well (#484).

The JAX-RS Exception Mapper maps errors as well (not just RuntimeExceptions?).
Thus the exception log is still readable when e.g. a NoClassDefFoundError? occurred.

The provider class is renamed:

RuntimeExceptionMapper -> CatchAllExceptionMapper

Close #484.

• Changeset: 8f6262f08b0855d4645fa82008aa22b432572a10
• URL: ​https://github.com/jri/deepamehta/commit/8f6262f08b0855d4645fa82008aa22b432572a10

[Jörg Richter <jri@…>]

In 93b6bdc5dfde0d24ed4ea2d17406634e52e67150/deepamehta:

Extend web layer exception handling (#484).

Also WebApplicationExceptions? are logged, provided their status is 4xx or 5xx.

Also a WebApplicationException?'s response is enriched with an exception info entity, provided no entity has been already provided by the application.

See #484.

[Jörg Richter <jri@…>]

In 7c1c92cfbe69c271f666a03d867dbfe958c32f98/deepamehta:

Webservice: log static resource exceptions (#484).

Also WebApplicationExceptions? thrown by static (non JAX-RS) resource filters are logged.

See #484.

[Jörg Richter <jri@…>]

In 9ec4ff0c941ed307022fa93504c0709295241ed4/deepamehta:

Webservice: unified exception handling (#484).

The webservice exception handling is unified for static and dynamic resources, in particular:

• Logging the exception.
• Enriching the response with an error entity.

See #484.

[Jörg Richter <jri@…>]

In 77be95b4af0179f3362c91c7920549840bcbbd53/deepamehta:

Webservice exceptions: define 405 status (#484).

See #484.

[Jörg Richter <jri@…>]

In 16685b03b230b03be462976f0c0a5bff66b086cb/deepamehta:

Core fix: read_requires_login=true works (#892).

If dm4.security.read_requires_login is set to true and the webclient is launched the browser's own login dialog appears.

This was broken in DM 4.7
Thank you, JuergeN, for reporting!

UniversalExceptionMapper?: for a failed static resource request the response headers and entity are properly set.

See #892.
See #484.