On Aug 20, 2010, at 5:53 PM, Stephen Colebourne wrote:
> On 20 August 2010 15:38, Paul Sandoz <Paul.Sandoz_at_oracle.com> wrote:
>> Yes, unfortunately exception mappers cannot be not scoped to the
>> media type
>> with @Produces and nor does content negotiation occur for exception
>> mappers.
> A nice to have for the next spec version :-)
>
Yes.
>> I think the best way to resolve this without resorting to doing
>> your own
>> conneg in the exception mappers is to support a common type for the
>> entity
>> returned by the exception mapper. Then use MessageBodyWriters
>> (MBWs) for say
>> XML/JSON and then a general one for */* that does not actually write
>> anything, which should result in the error pages of the web app
>> being used
>> (as no entity is written).
>>
>> Another solution is to eschew error pages with the wep app and use an
>> extension of Viewable (which encapsulates the status code or
>> Response) with
>> the reference to a JSP page and then use your own JSP templates
>> then have
>> MBWs or XML or JSON. The XML/JSON MBWs should take precedence other
>> the
>> general "*/*" MBW.
>>
>> The latter seems quite appealing to me. And eventually i want to
>> extend the
>> viewable support to work with XML and JSON-based templates.
> I looked into Viewable, but it would require a chunk more work, as I'm
> using Freemarker. Plus, where to put the Freemarker singleton wasn't
> obvious.
>
See here if it helps:
http://www.cwinters.com/blog/2009/04/03/jersey_freemarker_provider.html
> For the moment, I'm saying in the mappers "if acceptable media types
> contains webservice-data-type" then return a text/plain entity, else
> return the human facing web page.
>
OK, that a reasonable solution, more explicit than MBWs. For non 2xx
status codes the server should have more scope for the media type of
the representation it chooses for a response. The HTTP spec is silent
on the matter of status codes and what media types the client declares
is acceptable e.g. returning a 406 because an entity representation
for a 404is not acceptable seems wrong and then what do you return as
the entity for the 406 :-)
>
> I almost feel that a solution ought to be having two Application
> instances and a servlet filter to pick which one to use. Each
> Application would have its own mappers and resources, thus no
> conflicts. But, I've no idea if this would work.
>
I think it would be possible by overriding ServletContainer and
creating to instances of WebComponent but feels a little hacky.
It is currently not possible to have a "meta" JAX-RS application that
could route to another one. I think this in general is an interesting
idea and fits well with improving Jersey's/JAX-RS concept of
modularity (i like the idea of scoping MBWs/MBRs to certain modules
and allowing for Guice style registration).
Paul.