Hi, actually, forgot to ask one more question.
So what happens if a customer/user registers a custom
RuntimeExceptionMapper.
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
specific.
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
>>> <sberyozkin_at_talend.com> 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
>