Details

    • Steps to Reproduce:
      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:
      Workaround Exists
    • Workaround Description:
      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; }

      Description

      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.

        Gliffy Diagrams

          Attachments

            Activity

              People

              • Assignee:
                ron_sigal Ronald Sigal
                Reporter:
                movachon Matthieu Vachon
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated: