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 :-)
> 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.
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.
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.
Stephen