users@jax-rs-spec.java.net

[jax-rs-spec users] [jsr339-experts] Re: Re: Re: Re: Re: Re: Re: Null response entity and writer providers

From: Marek Potociar <marek.potociar_at_oracle.com>
Date: Tue, 26 Mar 2013 10:15:44 +0100

On Mar 26, 2013, at 8:28 AM, Sergey Beryozkin <sberyozkin_at_talend.com> wrote:

> Sorry, will cut some of the text immediately below,
>
> <snip/>
>>>>>>>
>>>>>>
>>>>>> IMO, if the JAX-RS method is returning a Response, then the JAX-RS
>>>>>> method metadata is the default and any piece of it can be overriden by
>>>>>> the user within the Response, including annotations. As an analogy, if
>>>>>> the JAX-RS method has a @Produces, and the Response is set with a
>>>>>> different media type, the overriden media type is honored.
>>>>>>
>>>>>> Also, +1 to no writers invoked if there is no response entity.
>>>>>>
>>>>>
>>>>> Sorry I may've moved the thread in some different direction, though
>>>>> indeed, all agree that no writers are to be invoked in the case of a
>>>>> null entity,
>>>>>
>>>>> What confuses me even more now is that you seem to mean "override",
>>>>> when referring to the annotations, while Marek thinks it is actually
>>>>> 'add'.
>>>>>
>>>>> We definitely need to have a common position on that :-)
>>>>
>>>> It MUST be add IMO. That's how it worked in JAX-RS 1.x RI.
>>>
>>> ResponseBuilder did not have a method for adding the annotation in 1.1 ?
>>
>> No, it did not. Btw. if you looked at the ResponseBuilder javadoc and
>> checked the "Since" information, you would not have to ask ;)
>> http://jax-rs-spec.java.net/nonav/2.0-SNAPSHOT/apidocs/javax/ws/rs/core/Response.ResponseBuilder.html#entity(java.lang.Object,
>> java.lang.annotation.Annotation[])
>> <http://jax-rs-spec.java.net/nonav/2.0-SNAPSHOT/apidocs/javax/ws/rs/core/Response.ResponseBuilder.html#entity(java.lang.Object,%20java.lang.annotation.Annotation%5B%5D)>
>>
> Yea, I know that. What confused me was you saying "add" was how it worked for JAX-RS 1.1 RI, there were no alternatives there really, and what we talk about now is about a new ResponseBuilder method.
>>>
>>>> Also, I think it would be wrong to ask users to specify their method
>>>> level annotations in the response builder, whenever they return a
>>>> Response from a resource method. Annotation instances are not
>>>> particularly easy to create...
>>>>
>>> Definitely not easy - why they users would *have* to do though ? It is
>>> optional, if the user does not add them then method level annotations
>>> are used.
>>> May be we are talking about slightly different things ?
>>
>> I cannot recall the exact scenario, but I certainly have ran into a case
>> where not adding the method level annotations broke some use case or
>> even 1.x RI tests. My hunch is that it had something to do with not
>> having the HttpMethod annotation available in a MBW or somewhere in the
>> filter or interceptor. IMO the use case for rb.entity(Object,
>> Annotation[]) is to e.g. provide support for additional annotations that
>> vary based on entity content (validation, extra entity metadata for
>> providers etc.) These typically do not interfere with static annotations
>> placed on a resource method.
>>
> OK, Having ResponseBuilder optionally adding the annotations to the statically declared ones makes sense, I just need to know the rules...
>>>
>>>> Filters can then choose to add or override the response annotations
>>>> as necessary.
>>>>
>>> How will the filter response context implementation know what the user
>>> wants ? It is either add or override.
>>
>> I don't get your question. Filters either know what they do or should
>> not touch the annotations at all. In general, I'd say that filters, too,
>> will more often add new annotations or remove individual ones, if needed
>> and will rarely replace all the annotations. But I do not know enough to
>> be able to completely exclude such use case. Having the option in the
>> API for low-level filters certainly does not hurt anyone.
>>
>
> The question is really simple.
>
> Given on your earlier feedback I've got the impression that when ContainerResponseContext#setEntity(Object entity, MediaType mt, Annotation[] annotations) method is called, the provided 'annotations' parameter effectively overrides what is already there.

Yes, that's still the case.

>
> You also say that the filters can remove some of the annotations. I think what you mean is the following:
>
> - ContainerResponseContext#setEntity(Object entity, MediaType mt, Annotation[] annotations) does override the previous context value

Yes.

> - if the user wants to remove some of the annotations then ContainerResponseContext#getEntityAnnotations would need to be used to build a new Annotations array to be set on the context
>
> Right ?

Correct.

Marek
>
> Sergey
>
>
>> Marek