On Nov 2, 2012, at 3:23 PM, Sergey Beryozkin <sberyozkin_at_talend.com> wrote:
> On 02/11/12 14:05, Marek Potociar wrote:
>> IMO, taking into account compatibility with existing applications, we
>> should not modify the exceptions thrown by these applications. So IMO,
>> this is what we should do:
>>
>> - JAX-RS runtime MUST throw a specific WAE subtype. This must be
>> indicated in the spec.
>
> OK
>
>> - JAX-RS runtime MUST NOT modify WAE instances raised by the application
>> code (to avoid compatibility issues).
>>
>> I filed a new Jira issue to track this:
>> http://java.net/jira/browse/JAX_RS_SPEC-306
>>
>> The above will ensure that JAX-RS as well as new applications are able
>> to leverage the new exception hierarchy. It also ensures that existing
>> applications that throw a WAE today will not se a change in the behavior
>> with the respect to application-thrown exceptions. Also, it avoids the
>> need to do too much magic at runtime.
>>
>
> Basically, this means the server-side exception mapping algorithm remains unchanged, right ?
Yes.
> I guess I'm fine with it - given it is simpler.
>
> FYI, I do not see how modifying ('promoting') application-thrown WebApplicationExceptions (note, only WebApplicationExceptions) to subclass instances will affect the compatibility, the promoted instance will still be handled by an existing WebApplicationException mapper.
>
> I guess it basically makes the idea of users having individual WebApplicationException Mappers not working. For example, one will have to have either a single, catch-all, WebApplicationException mapper, or,
> mappers for all individual WebApplicationException subclass mappers.
> As long as WebApplicationException is there the individual subclass mappers will miss on the exceptions they are meant to handle because WebApplicationException mapper will always be preferred...
I assume that new applications will be coded to throw the right sub-types. So the EM hierarchy should work well for them. Old applications are not using the hierarchy anyway. IMO it's more confusing to throw a WAE and then see it being catched by some exception mapper other than the one for WAE.
>
> We probably need to clarify it in the docs/spec
That's part of the issue I filed.
Marek
>
> Sergey
>
>> Marek
>>
>> On Nov 2, 2012, at 1:35 PM, Sergey Beryozkin <sberyozkin_at_talend.com
>> <mailto:sberyozkin_at_talend.com>> wrote:
>>
>>> Not that it should matter for the group and indeed for the spec :-),
>>> but I need to decide whether to optimize the existing (and buggy) CXF
>>> code which deals with mapping WebApplicationExceptions to subclass
>>> mappers on the server (and causes headaches for the users :-)) or
>>> simply revert to the original 1.1 code, which, for example,
>>>
>>> given a thrown WebApplicationExceptions(404) and the existence of
>>> WebApplicationException and NotFoundException mappers, will ignore
>>> NotFoundException mapper and select WebApplicationException mapper,
>>> while, a thrown NotFoundException will be mapped to NotFoundException
>>> mapper.
>>>
>>> As I said before, given that WebApplicationException(404) and
>>> NotFoundException represent the same error condition, and given the
>>> specific fact the runtime 'knows' about it by the virtue of both
>>> exception classes being part of API, it makes sense to make an
>>> exception to the algorithm specifically and only for the
>>> WebApplicationException hierarchy,
>>>
>>> but I won't be to upset with reverting to the original code either
>>>
>>> Cheers, Sergey
>>>
>>>
>>>
>>> On 30/10/12 10:41, Sergey Beryozkin wrote:
>>>> On 25/10/12 22:23, Sergey Beryozkin wrote:
>>>>> On 25/10/12 22:16, Marek Potociar wrote:
>>>>>> FWIW, what I recall we did agree upon, which is however not yet in the
>>>>>> spec is that we will make sure that all internal server-side WAEs will
>>>>>> be changed to proper sub-types.
>>>>>
>>>>> Can you clarify that a bit please ? What would be a difference between
>>>>> the internal code throwing WebApplicationException(500) and application
>>>>> code doing the same, as far as mapping either of these instances to a
>>>>> registered InternalServerErrorException mapper ?
>>>>
>>>> I'd like to get the agreement on this please. What makes me feel that
>>>> mapping of WebApplicationException to more specific exception mappers on
>>>> the server side should work is because say
>>>>
>>>> WebApplicationException(500) and InternalServerErrorException are meant
>>>> to represent exactly the same error condition, so, even though having
>>>> the current WebApplicationException handled by
>>>> InternalServerErrorException mapper does not work with the current
>>>> exception mapping algorithm, the exception has to be made specifically
>>>> for WebApplicationException hierarchy - it would just avoid the
>>>> ambiguities, example,
>>>>
>>>> "I want to have a generic exception mapping code, implemented with
>>>> WebApplicationException mapper, and something more specific done in case
>>>> of 500, implemented with InternalServerErrorException mapper".
>>>>
>>>> I know it all can be easily done at the WebApplicationException mapper
>>>> level itself, but the introduction of the new exception hierarchy will
>>>> inevitably lead to users wishing to write a cleaner base code for
>>>> handling all the exceptions without "ifs"
>>>>
>>>> Sergey
>>>>
>>>>>
>>>>>> Similarly, we agreed that on client side, proper sub-type will be
>>>>>> thrown based on response error code instead of a generic WAE.
>>>>>>
>>>>> That definitely makes sense
>>>>>
>>>>>> As for your question, I'm not sure it is wise to interfere with
>>>>>> application-thrown exceptions. (And I still cannot recall what we
>>>>>> decided...)
>>>>>>
>>>>> The question is whether some specific treatment is applied to WAE
>>>>> instances (irrespectively of where they originated from) or not, I've no
>>>>> strong opinion, in fact I've already implemented what I thought we
>>>>> might've agreed :-), but that is not important, I can revert, we just
>>>>> need to agree
>>>>>
>>>>> Sergey
>>>>>
>>>>>> Marek
>>>>>>
>>>>>> On Oct 25, 2012, at 11:10 PM, Marek
>>>>>> Potociar<marek.potociar_at_oracle.com
>>>>>> <mailto:marek.potociar_at_oracle.com>> wrote:
>>>>>>
>>>>>>>
>>>>>>> On Oct 25, 2012, at 10:57 PM, Sergey
>>>>>>> Beryozkin<sberyozkin_at_talend.com <mailto:sberyozkin_at_talend.com>>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> I would like to clarify the details of the way
>>>>>>>> WebApplicationExceptions are mapped on the server.
>>>>>>>>
>>>>>>>> Here is what I recall we talked about the other day.
>>>>>>>>
>>>>>>>> The code throws "new WebApplicationException(404)", and both
>>>>>>>> WebApplicationException and NotFoundException mappers are available.
>>>>>>>>
>>>>>>>> Given NotFoundException is effectively WebApplicationException(404),
>>>>>>>> NotFoundException mapper is chosen.
>>>>>>>
>>>>>>> Hmm... are you referring to a specific section in the spec? I cannot
>>>>>>> recall we agreed on that one, but I may be wrong.
>>>>>>>
>>>>>>>>
>>>>>>>> Similarly, if the code throws "new ServerErrorException(500)" and
>>>>>>>> both
>>>>>>>> ServerErrorException and InternalServerErrorException mappers are
>>>>>>>> available, InternalServerErrorException gets chosen.
>>>>>>>>
>>>>>>>> Is it the way it should work ? This obviously is an exception to the
>>>>>>>> default mapping algorithm, but it appears it is logical given that
>>>>>>>> the runtime understands the relationship between various API
>>>>>>>> exception classes
>>>>>>>
>>>>>>> As I said, I don't recall such agreement, but my memory is not
>>>>>>> flawless... If you see it in the spec, then we did agree on that :)
>>>>>>> (Which still doesn't mean we didn't if you don't see it there...)
>>>>>>>
>>>>>>> Marek
>>>>>>>
>>>>>>>>
>>>>>>>> Cheers. Sergey
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>