On Aug 12, 2009, at 10:01 AM, Martin Probst wrote:
>> But when something like Collection<T> or
>> Map<K, V> is returned the problem gets harder and i have not solved
>> it yet
>> to support a general resolving mechanism for any type variable
>> embedded
>> within a parameterized type.
>
> I think it's pretty much impossible to solve this correctly, due to
> erasure.
>
It is possible when the return type is declared. Which is why Jersey
can support the following:
public class A<T>
@POST
public T post(T t) {
return t;
}
}
public class B<String> extends A {}
Jersey looks at the generic type returned by a resource method and if
it is a type variable it will traverse the classes to determine that
String corresponds to T.
However the following is more problematic:
public class A<Collection<T>>
@POST
public Collection<T> post(Collection<T> t) {
return t;
}
}
And, although i have not tested it, i suspect the following is also
problematic:
public class A<T>
@POST
public Response post(T t) {
GenericEntity<T> ge = new GenericEntity(t);
return Response.entity(ge).build();
}
}
because the instance of "ge" will be processed when the returning
class and concrete class are not available to resolve T.
Paul.
> You could probably pick a MessageBodyWriter for the type declared on
> the method (as opposed to the actual type returned), which would get
> you closer, but that's probably an awkward solution that will then
> byte even more people...
>
> Martin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>