On 25/03/13 13:42, Marek Potociar wrote:
>
> On Mar 25, 2013, at 9:18 AM, Sergey Beryozkin<sberyozkin_at_talend.com> wrote:
>
>> Hi
>> On 15/03/13 15:48, Marek Potociar wrote:
>>>
>>> On Mar 15, 2013, at 1:28 PM, Sergey Beryozkin<sberyozkin_at_talend.com> wrote:
>>>
>>>> On 15/03/13 11:29, Marek Potociar wrote:
>>>>>
>>>>> On Mar 13, 2013, at 11:14 PM, Sergey Beryozkin<sberyozkin_at_talend.com> wrote:
>>>>>
>>>>>> On 13/03/13 14:27, Sergey Beryozkin wrote:
>>>>>>> On 13/03/13 14:25, Marek Potociar wrote:
>>>>>>>> I'd say that if there is no entity produced, no writers are invoked
>>>>>>>> and thus no writer interceptors are invoked. That's analogous to
>>>>>>>> processing empty inbound messages where the user does not try to
>>>>>>>> inject or read the entity.
>>>>>>>>
>>>>>>> That sounds OK, agreed
>>>>>>>
>>>>>> What should ContainerResponseContext return in case of the null response body and the resource method actually invoked, for example,
>>>>>>
>>>>>> public Book getBook() {
>>>>>> throw new SomeException();
>>>>>> }
>>>>>>
>>>>>> Mapper: maps it to Response with a null entity.
>>>>>>
>>>>>> The filters are processing this response, should they return 'null' for ContainerResponseContext for getEntityClass/Type/Annotations, or the actual Book type info ?
>>>>>
>>>>> Annotations should be always set from method.
>>>>> Type and Class should be only set for non-null results.
>>>>>
>>>> Yes, it helps, thanks. This is actually how I implement it now, though the user can reset the method-level annotations from the response filter
>>>
>>> That's fine,
>>>
>>
>> I've spotted that ResponseBuilder has also has a way to set the annotations, thus effectively overriding the method level annotations too.
>
> It's not overriding, it's adding. We discussed this earlier in this forum. IIRC it was Bill who asked.
>
OK. So ClientResponseFilter is 'overriding'/resetting, see you earlier
confirmation above, and ResponseBuilder is 'adding', is that right ?
>>
>> FYI, I'd actually prefer to remove the relevant ResponseBuilder method, ResponseBuilder#entity(Object entity, Annotation[] annotations) for the following reasons:
>>
>> - ResponseBuilder is all about building the response representation
>> - ContainerResponseFilter would be the perfect place to override the annotations whenever it is really needed
>> - All the data one passes to ResponseBuilder is next available at Response level but not the annotations - this will cause the issues in cases where Response copy is made in the presence of multiple JAX-RS implementations in a given container - this is actually not that rare at all....
>>
>> Do you agree it can make sense to tackle it ? I can open a JIRA for that, IMHO this kind of change is minor enough to do even at this stage
>
> No, I disagree. E.g. request filters on client may need to build an abort response and may need this functionality.
The client response is routed via the response filters, so rather than
have this foreign method on Response, why doin't we add it to
ClientResponseFilter ?
Sergey
>
> Marek
>
>>
>> Thanks, Sergey
>>
>>
>>
>>
>>> Cheers,
>>> Marek
>>>>
>>>> Cheers, Sergey
>>>>> HTH,
>>>>> Marek
>>>>>
>>>>>> I think it should be 'null' but as usual would appreciate that it is indeed the case
>>>>>> Sergey
>>>>>>
>>>>>>
>>>>>>> Cheers, Sergey
>>>>>>>> Marek
>>>>>>>>
>>>>>>>> On Mar 13, 2013, at 2:38 PM, Sergey Beryozkin<sberyozkin_at_talend.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi
>>>>>>>>>
>>>>>>>>> If we have a null response entity (example, with "void" resource
>>>>>>>>> method return types or Response having no entity set), do writer
>>>>>>>>> interceptors still get a chance to change it ? I think yes,
>>>>>>>>> WriterInterceptorContext has a setEntity() method,
>>>>>>>>>
>>>>>>>>> but given WriterInterceptor chain delegates eventually to
>>>>>>>>> MessageBodyWriter, I wonder what is the right answer there.
>>>>>>>>>
>>>>>>>>> I guess the runtime should indeed let the writers process Response
>>>>>>>>> with the empty entity, but stop short of delegating to
>>>>>>>>> MessageBodyWriter if the response entity is null...
>>>>>>>>>
>>>>>>>>> Sergey
>>>>>>>>
>>>>>
>>>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com