>>
>>>>>> 6. ContainerResponseContext.setEntity(Object, Annotation[], MediaType)
>>>>>>
>>>>>> I wonder if this method is needed, in this form - I'd really limit it to
>>>>>> ContainerRequestContext.*setEntity(Object)*: we can set MediaType on response headers directly if really needed.
>>>>>>
>>>>>> Annotation[]: this is inconsistent with the fact that ContainerRequestContext has getEntityClass and getEntityType methods and obviously we can not determine a correct Type from Object, hence getting Annotation[] passed seems unusual. The whole idea of actually making the runtime to believe that the method returns a class + type different from the pair which can be reflectively introspected does not seem like a good idea. Replacing the actual entity seems OK/reasonable - for a 'complete' replacement we can simply use a name-bound *blocking request* filter
>>>>>
>>>>> I agree that the method is a powerful tool, but I prefer we keep it in (also based on your follow-up discussion with Bill).
>>>>>
>>>>
>>>> OK. One minor issue remains, we have get getEntityType(), but no Type parameter is available in this method
>>>
>>> Isn't that something that should be inferred from the entity instance?
>>
>> Well, I guess there's a reason getEntityType() which returns 'Type' is there. If you expect Type and Class being the same then lets remove getEntityType given we have getEntity()
>
> The reason why getEntityType is there is that when the resource method call returns, the getter provides the information about the static return type of the method. Not sure if we need a similar type setter in filter. But I'm not strongly against or anything. Just that with all the filters I wrote so far I have not run into a use case where I would need such method. Please file a Jira issue if you feel strongly about it.
I'd prefer not to add a type setter but add one more parameter to
setEntity, if we have a method returning List<Book>, then, given that
setEntity can accept any Object, such as ArrayList<Chapter>, it makes
sense to add Type as another parameter...
Unless the use of generic wrapper utility classes is recommended in such
cases...
Cheers, Sergey
>
>>
>>>
>>>>
>>>>>> 7. ContainerResponseContext.getHeaders& getStringHeaders - both return mutable maps, the latter method only supports remove operations: can we have getHeaders() only ? A single method dedicated to modifying response headers ?
>>>>>
>>>>> The getStringHeaders() provide a convenient string-based view of getHeaders(). There are many cases where this is useful. We may updated the javadoc so that getStringHeaders() do not indicate support for removal operations, if you want, but the method should stay.
>>>>>
>>>> If you can agree to make this view read only then it would simply things IMHO
>>>
>>> Ok, I don't have any problems with removing the mutability requirement from the javadoc.
>>
>> That simplifies things a bit
>
> Done.
>
> Marek
>>
>> Cheers, Sergey
>>
>>>
>>> Marek
>>>
>>>> Sergey
>>>>
>>>>> Marek
>>>>>
>>>>>>
>>>>>> That is it for now
>>>>>> Thanks, Sergey
>>>>>
>>>>
>>>>
>>>
>>
>>