The problem is not with the generic entity type - the problem is with getting the generic callback type information as such so that the response data can be properly unmarshalled based on the callback generic type information.
I didn't want to have all JAX-RS implementations copy the internal algorithms implemented in the GenericType. So I had to choose between changing it to an subclass of a GenericType and adding Class<?> getRawType() and Type getType() methods to the interface and let users implement it with every single InvocationCallback instance. I chose the first option as I assume users would not want to spend time implementing those methods over and over again. I also assume that in most cases the callback implementation will be an anonymous sub-class. Those few other cases where the callback would want to inherit from another class can be resolved by delegation.
With the change, the type calculation is reused, users don't need to do anything extra to provide it, and the most common use case scenarios remain simple. I think this is the most efficient solution. Also, since the InvocationCallback conveys the response type information, the solution is also very natural.
Marek
On Jun 27, 2012, at 12:25 AM, Bill Burke wrote:
> Was looking in GIT master and saw that InvocationCallback is now an abstract class? I hope it can stay as an interface. If a user is havin generic type issues then they should use a InvocationCallback<Response>.
>
> Bill
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>