users@jersey.java.net

Multiple ExceptionMappers for the same type of exception

From: Brian Gilstrap <brian_at_ociweb.com>
Date: Tue, 17 Nov 2009 22:21:59 -0600

Hello.

I've been having great success working with Jersey and JAX-RS, but one
thing I tried recently doesn't work. Re-reading the 1.0 spec suggests
that it may not be supported.

I would like to have multiple sets of classes which work together to
'render' a set of resources into a particular MIME type. As an
example, I have a sample system which is a simple music information
database (artists, CDs, and tracks). I want to be able to render these
conceptual resources as HTML, XML, or JSON (and in a manner that could
be extended to other types in the future).

Doing this in a manner which keeps each of the renderings separate/
orthogonal from each other requires that I have multiple
ExceptionMappers for the same exception which produce different media
types. I had hoped that I could do something like this:

=================
package net.gilstraps.music.html;

@Provider
@Produces( "text/html" )
public class NoSuchArtistMapper implements
ExceptionMapper<NoSuchArtistException> {
        // ...
}

=================
package net.gilstraps.music.xml;

@Provider
@Produces( "application/music-xml" )
public class NoSuchArtistMapper implements
ExceptionMapper<NoSuchArtistException> {
        // ...
}

=================
package net.gilstraps.music.json;

@Provider
@Produces( "application/json" )
public class NoSuchArtistMapper implements
ExceptionMapper<NoSuchArtistException> {
        // ...
}

=================

Unfortunately, when I did this Jersey seemed to pick one of the three
ExceptionMapper classes at random and used that for all exceptions. I
re-read the spec and realized that no discussion about @Produces or
selecting amongst exception mappers based upon media types is in the
spec. So, that leads me to think that this is not supported by the
specification.

So, I have a few questions:

1) Is this unsupported by the spec?
2) If it is supported, how do I make it work/
3) If it is not supported, why not? To put it another way: is there
some really thorny issue that makes it useless for me to request this
as a feature in a future version of the spec?
4) If this seems like a reasonable thing for a future spec, how do I
go about suggesting it to the working group in the manner most likely
to get my request noticed and seriously considered?

Thanks in advance,
Brian Gilstrap