dev@jsr311.java.net

Re: JSR311: Draft of the JAX-RS 2.0 JSR

From: Ryan de Laplante <rdelaplante_at_gmail.com>
Date: Mon, 15 Nov 2010 21:39:05 -0500

Hi,

I'm not a member of the mailing list, so please let me know if you let
this message through.

Somehow I stumbled across this thread on markmail tonight and wanted to
comment:


Bill de hÓra wrote:
> One practical problem I've seen is that real world systems don't
> always return errors in the same format as requested by the client
> (assuming the app developer requested anything at all, again common).
> Simple example - tomcat/jetty throwing up html error pages. We can
> argue this is quality problem with the server but it's ugly on clients
> when it happens and the entity binding blows up. I'd like to see
> something that echoes the exception mapper on the server side of
> JAX-RS. Another possibility is allocating handlers onto response codes.

This issue came up in GlassFish/Jersey in January 2010 and I started a
long forum thread about it:

http://www.java.net/forum/topic/glassfish/glassfish/jax-rs-error-code-500-glassfish-html-error-page-0

It resulted in changes to both Jersey and GlassFish:

https://glassfish.dev.java.net/issues/show_bug.cgi?id=11423


I thought you may be interested in this information when designing the
feature.

I was developing a GlassFish/Jersey/JAX-RS service for consumption by a
BlackBerry app. A separate issue I ran into is that all traffic is
proxied through RIM and they totally ruin the headers and error
responses. Plus certain HTTP methods are not supported. Maybe look
into that a bit more and see if there's anything that can be done so we
could design and code the RESTful web service "the right way", but at
the same time support mental clients like BlackBerry. Maybe this is
possible already... I haven't touched JAX-RS since February or March.


Thanks,
Ryan