Sounds good, thanks
Sergey
On 31/08/15 18:05, Marek Potociar wrote:
> 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