On Jan 14, 2010, at 8:16 AM, Markus Karg wrote:
> 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*
No. JAX-RS can be used for writing RESTful Web applications serving
HTML, XML and JSON depending on what the client accepts (e.g. see the
RESTful admin support, or stuff what is being done in Apache Camel).
There is stuff in Jersey to enable just that (the MVC stuff).
I do not think this issue is specific to just JAX-RS/Jersey but to any
Servlet-based Web application. Invariably when one wants to deploy a
Web application in production then the default error pages will likely
be changed to something particular to the Web application. (And i do
see value in GF providing support for just that with customizable
themes.)
Paul.
> 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
>
>
>