jersey
  1. jersey
  2. JERSEY-1557

Whether to use sendError or setStatus should be configurable

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 1.15
    • Fix Version/s: 1.15
    • Component/s: core
    • Labels:
      None
    • Environment:

      (Weblogic 10.3.2)

      Description

      This issue applies to the "jersey-servlet" module.

      In current versions of Jersey, any error with a status code above 400 is sent to the container with "sendError". See WebComponent.java#finish and ServletContainer.java#service. This has the effect that responses with a status code >= 400 is sent to the underlying container for further processing, i.e. using the <error-page> directives in web.xml. setStatus would not deliver it to the container. See http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpServletResponse.html#setStatus(int).

      This use of sendError seems to be introduced in JERSEY-389 and is probably desirable for many projects, however, other projects may always want to use setStatus over sendError. I'll give an example that applies to my current project:

      • JSF and Jersey is used in the same webapplication. In the context of JSF-errors, we use web.xml <error-page> directives for error handling (e.g. 403) and <error-page> with <exception-type>java.lang.Throwable</exception-type> for top level exception handling. These directives return HTML, and in the case of some errors, go via JSF first generate the HTML. Depending on the error, some may contain redirects to the login page.
      • For Jersey we use ExceptionMappers and ExceptionMapper<Exception> as the top level error handling. Although the correct status code is returned, it will be delivered to the container since sendError is returned. If the status code matches with one defined in web.xml, the container will proceed with these <error-page> directives. This has the undesired effect of a) returning HTML to the client, b) possibly giving redirects and the login page in return, c) triggering code in JSF or an other framework if the <error-page> is set to a servlet page.

      From a API consumer perspective, we want to always return valid JSON/XML to the client without side effects from <error-page> directives.

      Suggestion: an init-param to jersey that toggles between todays behavior and always using setStatus to avoid container error handling.

        Activity

        Hide
        Martin Matula added a comment -

        Simply add an entity to your response - if the error response contains an entity, the container processing will be skipped.

        Show
        Martin Matula added a comment - Simply add an entity to your response - if the error response contains an entity, the container processing will be skipped.
        Hide
        ralf.s.lorenz added a comment -

        This week we stumbled accross this topic and it took a while to find out that jersey requires an entity to be set at responses with status codes greater that 400.
        As far as I know is it not obligatory to have a body at a http response so could someone explain to me why jersey requires to have a body set or rather calls response.sendError in case of an empty body?

        Show
        ralf.s.lorenz added a comment - This week we stumbled accross this topic and it took a while to find out that jersey requires an entity to be set at responses with status codes greater that 400. As far as I know is it not obligatory to have a body at a http response so could someone explain to me why jersey requires to have a body set or rather calls response.sendError in case of an empty body?

          People

          • Assignee:
            Martin Matula
            Reporter:
            mobmad
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: