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.
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
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
>>>>>>
>>>
>