I.e, if it is accepted that indeed it is fine for the runtime to report
various spec-related error conditions as WAE (and its subclasses),
then what is the correct way for the runtime to handle such WAEs:
- use its own WAE mapper (and thus this mapper may compete with a custom
RuntimeException mapper which is meant to catch WAE too)
- let the custom mappers map such WAEs and only do the mapping itself if
the custom mapper is not available
Santiago, what do you think ? Or may be I should ask, how Jersey does it
:-) ?
Cheers, Sergey
On 28/08/15 15:15, Sergey Beryozkin wrote:
> 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
>>
>