Ticket #484 (closed Enhancement: fixed)

Opened 7 years ago

Last modified 5 years ago

Web layer exception handling

Reported by: jri Owned by: jri
Priority: Major Milestone: Release 4.2
Component: DeepaMehta Standard Distribution Version: 4.1
Keywords: Cc: dgf, Malte
Complexity: 3 Area: Application Framework / API
Module: deepamehta-webservice

Description

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.

Change History

comment:1 Changed 7 years ago by jri

  • Status changed from new to accepted

comment:2 Changed 7 years ago by 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

comment:3 Changed 7 years ago by jri

  • Status changed from accepted to closed
  • Resolution set to fixed

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

comment:4 Changed 7 years ago by jri

  • Status changed from closed to reopened
  • Resolution fixed deleted

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.

comment:5 Changed 7 years ago by Jörg Richter

  • Status changed from reopened to closed
  • Resolution set to fixed

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.

comment:6 Changed 7 years ago by 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.

comment:7 Changed 5 years ago by 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.

comment:8 Changed 5 years ago by 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.

comment:9 Changed 5 years ago by 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.

comment:10 Changed 5 years ago by Jörg Richter <jri@…>

In 77be95b4af0179f3362c91c7920549840bcbbd53/deepamehta:

Webservice exceptions: define 405 status (#484).

See #484.

comment:11 Changed 5 years ago by 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.

Note: See TracTickets for help on using tickets.