users@jersey.java.net

Multiple exception mappers for different response types

From: Brian Gilstrap <brian_at_gilstraps.net>
Date: Tue, 24 Nov 2009 10:15:56 -0600

[repeating due to lack of any responses]

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 resources as HTML, XML, or JSON (and in a manner that could be extended to other types in the future).

Keeping 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,
Brian Gilstrap