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

From: Sergey Beryozkin <>
Date: Mon, 25 Mar 2013 11:18:14 +0300

On 15/03/13 15:48, Marek Potociar wrote:
> On Mar 15, 2013, at 1:28 PM, Sergey Beryozkin<> wrote:
>> On 15/03/13 11:29, Marek Potociar wrote:
>>> On Mar 13, 2013, at 11:14 PM, Sergey Beryozkin<> 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

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