[jax-rs-spec users] Re: Default WebApplicationException mapper vs custom mappers

From: Sergey Beryozkin <>
Date: Fri, 28 Aug 2015 15:15:46 +0100

Hi, actually, forgot to ask one more question.

So what happens if a customer/user registers a custom

If we have a runtime-initiated WebApplicationException going via the
usual exception mapping flow then which provider wins, the custom one
which is less specific or the runtime-provided
WebApplicationExceptionMapper<WebApplicationException> one which is more

If we use a spec text only then it is the runtime provided
WebApplicationException which wins. (re to CXF here).

However, what if some other JAX-RS implementation implements the spec
requirements (re the error statuses) by for example having a
RuntimeExceptionMapper<RuntimeException> where it checks if
RuntimeException is an instance of WebApplicationException, etc, given
that the spec does not mandate how the the runtime should map such
exceptions ? In this case, a custom RuntimeExceptionMapper will get the
control when WebApplicationException is thrown by the runtime, which
means we have a non-portability situation between the two frameworks:
the custom RuntimeExceptionMapper can catch WebApplicationException in
one runtime but not in the other one.

Is there an implicit understanding that every JAX-RS 2.0 runtime offers
a default WebApplicationExceptionMapper<WebApplicationException> ?
Should the spec advise it directly ? If not then where is the
portability guarantee re mapping WebApplicationException ?

Thanks, Sergey

On 28/08/15 14:42, Sergey Beryozkin wrote:
> Hi Santiago
> Indeed, it does make sense, I agree. It would not be perfect at all
> otherwise.
> Thanks for the confirmation...
> Cheers, Sergey
> On 28/08/15 14:34, Santiago Pericasgeertsen wrote:
>> Hi Sergey,
>> I believe what youíre describing itís the expected behavior. There
>> are a number of extension points that applications can tap into that
>> can impact the runtime (filters, reader/writers, etc.). The spec
>> talks about throwing exceptions, how exceptions are handled depends
>> on how the application is configured.
>> In your example, it may be that a certain application wants to
>> catch that exception and return a redirect status code to maintain
>> backward compatibility with some old clients.
>> ó Santiago
>>> On Aug 28, 2015, at 6:18 AM, Sergey Beryozkin
>>> <> wrote:
>>> Hi
>>> The spec talks about returning HTTP error statuses in a number of
>>> cases.
>>> In CXF this is realized by the runtime throwing
>>> WebApplicationException (or its subclasses) and having a default
>>> WebApplicationExceptionMapper<WebApplicationException> which
>>> converts the exception.
>>> What occurred to me right now is that well, if a user registers its
>>> own custom WebApplicationExceptionMapper, then this custom mapper
>>> may in principle may get the runtime becoming non-compliant.
>>> For example, if the resource has no method matching a given path
>>> then NotFoundException is thrown (by CXF at least) and the default
>>> mapper which CXF ships handles it and converts to 404. What if a
>>> custom NotFoundException mapper is available and it sets 400 ? This
>>> example is probably a bit unrealistic because it mapping
>>> NotFoundException is unlikely to be treated differently by different
>>> mappers, but with other exceptions it is possible in principle.
>>> My question is:
>>> - Can the runtime allow custom exception mappers deal with exception
>>> such as NotFoundException that are thrown by the runtime itself ?
>>> I.e, has the runtime make sure that when it enforces all the spec
>>> related error conditions *it does not throw the exceptions* because
>>> if it does then the custom mapper can always catch it first; or if
>>> it does throw the exception in such cases it make sure the code
>>> which maps exceptions to exception mappers is bypassed ?
>>> Thanks, Sergey