I'd like to mention that GlassFish should be aware of the difference
between a JAX-RS response and a servlet response. Why? Because JAX-RS is
an API for writing *services* and the W3C just said *should* but not
*must*. So it should be up to the service author whether or not he
follows the W3C's wish. If the author thinks that it makes no sense to
have an error page, then none should get presented. This might be
different for a servlet, that mostly will return HTML to end users,
where virtually most authors don't care about whether there is an error
page contained or not. I mean, the JAX-RS team decided very carefully
and intentionally that a JAX-RS resource or engine is not mandatorily a
servlet. So GlassFish as the Java EE RI should understand that
difference and respect it. If the JAX-RS service authors want an error
page, they will provide one. If they don't want one, then they will
provide none. As a result, the only valid solution from the view of the
JAX-RS specification is that GlassFish must learn not to show an error
page. It is not Jersey's fault that one is shown, it is GlassFish's!
Regards
Markus
From: Jan.Luehe_at_Sun.COM [mailto:Jan.Luehe_at_Sun.COM]
Sent: Mittwoch, 13. Januar 2010 23:16
To: users_at_glassfish.dev.java.net
Subject: Re: JAX-RS error code 500 = GlassFish HTML error page
On 01/13/10 01:22 PM, glassfish_at_javadesktop.org wrote:
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);
}
ld that work for you?
I am not writing a servlet -- I am writing a JAX-RS service so that does
not work for me.
I know, my comment was more targeted towards the Jersey integration
servlet, and therefore Paul.
I'm not familiar with any Jersey implementation details, but I suspect
that when you output an entity body to the JAX-RS response (when
returning an error), this will commit the corresponding HTTP response,
and therefore, the web container's error page mechanism (and its
default error page) will be completely bypassed, even if a matching
error page
existed. In other words, the GlassFish web container won't "take over
the response",
as you put it.
If I understood your original request correctly, you wanted to be able
to get the above behaviour (of GlassFish not interfering with your
response) *without* having to provide an entity in the JAX-RS response.
As I mentioned earlier, the Servlet spec requires that the web
container use the sendError method to send 4xx and 5xx status
responses, so that the error mechanism may be invoked. sendError is
required to clear the response buffer and return the contents of the
error page. Note that the web container will *not* invoke sendError
semantics if the response has already been committed.
So the trick is to ensure that the response has already been committed
when it is returned through the web container. Apparently, outputting
an entity to the JAX-RS response has this effect, but perhaps the
Jersey integration servlet could commit (under the circumstances
mentioned in this thread) the response even if no entity body has been
written.
Jan
However, if GlassFish is following the W3C and servlet specifications to
the letter, then I should be including an entity body whenever returning
an error status. When I return an entity body, GlassFish lets it
through. I think this morning I tested with error pages configured in
web.xml, and GlassFish allowed my response to be sent as-is to the
client even though an error page was defined for that error number.
That is what I want to happen. I suspect removing my entity body would
have caused GlassFish to display the appropriate error webpage.
Thanks,
Ryan
[Message sent by forum member 'rdelaplante' (ryan_at_ijws.com)]
http://forums.java.net/jive/thread.jspa?messageID=380759
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
For additional commands, e-mail: users-help_at_glassfish.dev.java.net