users@glassfish.java.net

Re: JAX-RS error code 500 = GlassFish HTML error page

From: Jan Luehe <Jan.Luehe_at_Sun.COM>
Date: Wed, 13 Jan 2010 12:50:57 -0800

Ryan,

On 01/13/10 08:19 AM, glassfish_at_javadesktop.org wrote:
> In the ticket I created, I suggested that GlassFish continue to display error pages (defined in web.xml, or the defaults), except when the response is sent by a JAX-RS resource. That's how it should be. Right now I have to disable my error pages, so if users try to access a web page that does not exist they will not see a pretty 404 error. I had to do that so the JAX-RS API would be usable. So, I don't think my ticket should have been closed, or at least it should have been changed to an RFE.
>

I mentioned the "errorReportValve" property as a way to customize or
completely disable the default error page for a given virtual-server
(and all the applications deployed to it).

The Servlet spec (Section SRV 10.9.2: "Error Pages") has this:

  The default servlet and container will use the sendError method to
  send 4xx and 5xx status responses, so that the error mechanism may be
  invoked.

This means that if your Servlet throws an exception, the error
mechanism will be invoked, which attempts to map the status code or
exception type to an error page declared in the deployment descriptor.

Earlier in this thread, you mentioned a quote from the W3C
specification for HTTP response codes in the 4xx and 5xx ranges:

  Except when responding to a HEAD request, the server SHOULD include
  an entity containing an explanation of the error situation.

This is where the default error page comes into the picture.

If you don't have any error pages configured for your app and want to
bypass the default error page, you could do something like this in your
servlet's service method:

    try {
        // some code here
    } catch (Throwable t) {
        response.setStatus(500);
        response.flushBuffer();
        // rethrow
        throw new ServletException(t);
    }

Would that work for you?


Jan

>
>
>
>> The old story... when does the GF team finally
>> understand that it is
>> needed to cut off support for those pseudo-features
>> with major GF
>> releases? I mean, it can't be true that one install
>> the Java EE 6 RI and
>> first he has to do is to switch off things preventing
>> to act like a
>> clean Java EE 6 RI. This is ridiculous. If some
>> people like those
>> derivations from the spec, then pack all of them in a
>> special legacy
>> profile which *those* people have to explicitly
>> switch *on*... <very
>> angry/>
>>
>> Regards
>> Markus
>>
>> ------------------------------------------------------
>> ---------------
>> To unsubscribe, e-mail:
>> users-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail:
>> users-help_at_glassfish.dev.java.net
>>
> [Message sent by forum member 'rdelaplante' (ryan_at_ijws.com)]
>
> http://forums.java.net/jive/thread.jspa?messageID=380677
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>