Hi
Recall I was asking whether response filters should unwrap or return as
is GenericEntity instances and I believe all agreed that the filters
should unwrap, because, after all, they have API to allow for it
(getEntityType(), getEntityClass()).
Slightly different path:
Response r = Response.entity(new GenericEntity<List<String>>(strings) {
>> });
Object entity = r.getEntity();
Do we return List or GenericEntity instance here ? It appears to me it
should be GenericEntity, because returning List alone loses the type
information which was supposed to be preserved with GenericEntity in the
first place.
From the implementation perspective I can see how Response can unwrap
but then internally provide the extra type info to the runtime and filters.
The case where this does not work well is ClientRequestFilter blocking
with a generic entity and the client code getting the unwrapped entity
and having to process it the untyped way.
That said we have Response.readEntity(GenericType). So I guess
Response.geEntity() should unwrap GenericEntity in the end.
Does anyone think it should not ?
Cheers, Sergey
On 22/03/13 21:21, Bill Burke wrote:
> I'm assuming GenericEntity is *not* returned. At least, that's the way
> I've implemented it.
>
> On 3/22/2013 5:03 PM, Sergey Beryozkin wrote:
>> On 22/03/13 18:19, Marek Potociar wrote:
>>> I'm not sure I understand, can you provide a piece of code that
>>> describes the use case you have in mind?
>>>
>> @GET
>> public Response get() {
>> List<String> strings = ...
>> return Response.entity(new GenericEntity<List<String>>(strings) {
>> });
>> }
>>
>> public class MyResponseFilter implements ContainerResponseFilter {
>> public void filter(ContainerResponseContext context) {
>> //what is the entity, List instance or GenericEntity instance
>> context.getEntity();
>>
>> //what is the entity class, List or GenericEntity class
>> context.getEntityClass();
>>
>> //what is the entity type, parameterized type representing
>> List<String> or GenericEntity class ?
>> context.getEntityType();
>> }
>> }
>>
>> I think the filters should not really see GenericEntity, though they can
>> set a new entity as GenericEntity, but as far as the view of it is
>> concerned, GenericEntity is unwrapped
>>
>> See what I am trying to clarify ?
>>
>> Thanks, Sergey
>>
>>
>>> Marek
>>>
>>> On Mar 22, 2013, at 5:05 PM, Sergey Beryozkin<sberyozkin_at_talend.com>
>>> wrote:
>>>
>>>> Hi Again - can I get some clarifications please ?
>>>> I'd rather not to browse through the RI code to deduce the answer :-)
>>>> I don't think I should open a JIRA for this, very minor question, so
>>>> would rather prefer to keep it on the list
>>>>
>>>> Cheers, Sergey
>>>> On 19/03/13 21:20, Sergey Beryozkin wrote:
>>>>> On 18/03/13 17:13, Sergey Beryozkin wrote:
>>>>>> Hi
>>>>>>
>>>>>> What ContainerResponseFilter should return in getEntity(),
>>>>>> getEntityClass() and getEntityType(), when the application code uses
>>>>>> GenericEntity class ?
>>>>>>
>>>>>> I'm thinking that GenericEntity needs to be 'unwrapped' by the filter
>>>>>> context implementation, but then if the filter implementation sets
>>>>>> "new GenericEntity..." then I guess it needs to get it back, in
>>>>>> getEntity(), so may be after all
>>>>>>
>>>>>> getEntity(), getEntityClass() and getEntityType()
>>>>>>
>>>>>> should return GenericEntity instance + GenericEntity.class ?
>>>>>
>>>>> I'm still thinking that 'unwrapping' GenericEntity makes sense even
>>>>> if a
>>>>> given filter replaces a current entity with GenericEntity, after all
>>>>> the
>>>>> filter which replaces an entity is more interested in the follow-up
>>>>> filters and writers to get the updates.
>>>>>
>>>>> So, to summarize, relevant ContainerResponseFilter getters should
>>>>> never
>>>>> return GenericEntity if the current entity happens to be GenericEntity
>>>>> (instance, class, type) but unwrap it.
>>>>>
>>>>> Agreed ?
>>>>>
>>>>> Cheers, Sergey
>>>>>
>>>>>
>>>>>>
>>>>>> Thanks, Sergey
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com