I did reply to your original message:
https://jersey.dev.java.net/servlets/ReadMsg?list=users&msgNo=8719
Marc.
On Nov 24, 2009, at 11:15 AM, Brian Gilstrap wrote:
> [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