I think that section 3.3.4 of the JAX-RS 2.0 spec describes the case of processing WAE:
WAE is a “special” exception type that is processed as described in step one of the section. IOW, RuntimeException mapper should not be ever invoked for WAE, because WAE gets always mapped to a response as per step one and never gets to any later step.
HTH,
Marek
> On 31 Aug 2015, at 11:02, Sergey Beryozkin <sberyozkin_at_talend.com> wrote:
>
> 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
>>>
>>
>