On Dec 16, 2009, at 8:41 PM, Casper Bang wrote:
> Marc Hadley wrote:
>> What component/class does your @ExceptionHandler hand the job of
>> mapping to ? IOW do you envision a local (vs global) equivalent of an
>> ExceptionMapper ? If so wouldn't that also need to be listed in the
>> annotation so the framework knows which one to use ?
> I am not sure how and whereto it would map (only having mocked up the
> feature), but I would expect the global ones to be last resort and
> default (just like Apache's error pages are). Class-wide ones would
> take
> precedence over global ones and method declared ones would take
> precedence over everything else.
>> I've found global exception mappers (implements ExceptionMapper)
>> very useful in my work but that is a fairly uniform API with a
>> small set of throwables. I can see it might be useful to be able to
>> scope exception mappers such that you can select amongst multiple
>> different mappers for the same exception depending on context - is
>> that the kind of thing you have in mind ?
> Exactly! For instance, a part of my API uses the path as a fairly
> sophisticated query language for composing charts ( Chart -> Plot ->
> Meter -> Registration + various meta data). I would like to be able to
> report a 400 (Dude you ain't making sense) but in this response also
> include a viewable (if consumer accepts html) which lets the browser
> render an editor and/or debugger. I just see it as a flexible
> annotation
> based ExceptionMapper which is scoped and picked up on-site rather
> than
> globally scoped on some arbitrary provider path.
>
You would like to annotate an ExceptionMapper with @Produces ?
Note that it should be possible to decide whether to return a Viewable
entity or not by placing some logic in the toResponse method using the
JAX-RS variant features. Or you can inject HttpContext and get the
Content-Header set on the response.
Paul.