On 6/28/12 11:49 AM, Marek Potociar wrote:
>
> As I tried to explain, this issue is not about specifying response type in the user application code. It is about getting the InvocationCallback generic type information in JAX-RS implementations (Jersey, CXF, RestEasy...). It is also about making sure the users avoid pitfalls with reification failures discussed above by failing early and in a documented way.
>
The only time a JAX-RS container would not be able to get the type
information is this case:
class MyGenericCallback<T> implements InvocationCallback<T> {}
// application code
MyGenericCallback<String> callback;
Even this case I've got 3 fairly simple workarounds. In summary -
* explict inheritance
class StringCallback extends MyGenericCallback<String>{}
* inner class inheritance
MyGenericCallback<String> callback = new MyGenericCallback<String>(){};
* Force the user to use javax.ws.rs.core.Response and readEntity().
And, in summary again, the regular client API has the same generic type
issues and requires special knowledge of how GenericType works with java
generics. So why is it such a stretch for them to do the same with
InvocationCallback?
I guess I've exhausted my arguments. I hope somebody else chimes in here.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com