Uploaded image for project: 'RESTEasy'
  1. RESTEasy
  2. RESTEASY-804

Exception Mappers breaks caching

XMLWordPrintable

    • Hide

      Create a service and a method with @Cache. Add a custom exception mapper. At the first request, method result will be returned. At second request, Not-Modified (304) response should be returned. Instead, the exception mapper will be executed.

      Show
      Create a service and a method with @Cache. Add a custom exception mapper. At the first request, method result will be returned. At second request, Not-Modified (304) response should be returned. Instead, the exception mapper will be executed.
    • Workaround Exists
    • Hide

      The current workaround is to code the ExceptionMapper implementation to treat NoLogWebApplicationException differently. Here the code we use currently to workaround the issue:

      if (exception instanceof WebApplicationException) {
    Response response = ((WebApplicationException) exception).getResponse();
    if (response == null || response.getStatus() > 399) return handleException(exception);

    return response;
}
      Show
      The current workaround is to code the ExceptionMapper implementation to treat NoLogWebApplicationException differently. Here the code we use currently to workaround the issue: if (exception instanceof WebApplicationException) { Response response = ((WebApplicationException) exception).getResponse(); if (response == null || response.getStatus() > 399) return handleException(exception); return response; }

      When using a custom exception mapper in conjunction with caching (using resteasy-cache-core), caching can break. Let my explain in greater details.

      When a Not-Modified (304) response must be issued for a given request, it is processed via the class ServerCacheInterceptor. In this class, when it determines that content was not modified, it uses a NoLogWebApplicationException an attach into it the Not-Modified (304) response.

      This exception will then makes it way to the SynchronousDispatcher class which is responsible of handling exceptions. Normally, this class will trap the exception in the method handleWebApplicationException which will return the Not-Modified (304) response that is inside the exception.

      However, when you setup an execution mapper, the newly configure exception mapper will be used to process the exception. If the custom exception mapper is not coded to handle the case that a NoLogWebApplicationException can contain a Not-Modified (304) response, it will break caching.

      In my opinion, the transportation of the Not-Modified (304) response must be done in a different manner so it does not interfer with custom exception mapper.

      The current way imposed to the custom exception mapper to be aware of the caching behavior of the NoLogWebApplicationException.

        1. exception-mapper-cache-problem.zip
          5 kB

              rsigal@redhat.com Ronald Sigal
              movachon Matthieu Vachon (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated: