Skip to main content

[jsr339-experts] Re: InvocationCallback changing?

  • From: Bill Burke <bburke@...>
  • To: jsr339-experts@...
  • Subject: [jsr339-experts] Re: InvocationCallback changing?
  • Date: Wed, 27 Jun 2012 18:22:03 -0400

One more thing I'd like to add:

I don't think the problem you describe exists anyway.  Consider this:

class MyCallback implements InvocationCallback<List<Foo>>
{
   public void complete(List<Foo> foo) {
...
}

The type information here can be obtained at runtime and the entity can be correctly unmarshalled. We already do this for MessageBodyReader/Writer.

I also submitted a JIRA so that this doesn't fall through the cracks:

http://java.net/jira/browse/JAX_RS_SPEC-221



On 6/27/12 12:19 PM, Bill Burke wrote:


On 6/27/12 5:33 AM, Marek Potociar wrote:
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.


Of course...Which is why we have GenericType for this type of scenario

I didn't want to have all JAX-RS implementations copy the internal
algorithms implemented in the GenericType.

Why would they need to do this?  Just use 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.


I really really disagree.  Abstract classes severely constrain your
options when class designing so what you are doing is really bad.    How
would you handle generic types in a regular client request?  Answer is,
you'd use a GenericType

i.e.

Response response = client.target("...").request().get();
List<Foo> list = response.readEntity(new GenericType<List<Foo>>(){});

Why is InvocationCallback a special case? So, do the same thing for
InvocationCallback...

public class MyCallback implements InvocationCallback<Response>
{

    public void complete(Response response) {
       List<Foo> list = response.readEntity(new
GenericType<List<Foo>>(){});
    }
}

Or,

public class MyCallback implements InvocationCallback<Response>
{
    private Type type;
    public MyCallback(Type type)
    {
       this.type = type;
    }

    public void complete(Response response) {
       List<Foo> list = response.readEntity(new GenericType(type));
    }
}

You're overthinking this... Get some sleep, have a coffee, maybe a
snack, kiss your wife, then revisit this problem and you'll see what I
mean.

Bill


--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com




[jsr339-experts] InvocationCallback changing?

Bill Burke 06/26/2012

[jsr339-experts] Re: InvocationCallback changing?

Marek Potociar 06/27/2012

[jsr339-experts] Re: InvocationCallback changing?

Bill Burke 06/27/2012

[jsr339-experts] Re: InvocationCallback changing?

Bill Burke 06/27/2012

[jsr339-experts] Re: [jax-rs-spec users] Re: InvocationCallback changing?

Marek Potociar 06/28/2012

[jsr339-experts] Re: [jax-rs-spec users] Re: InvocationCallback changing?

Bill Burke 06/28/2012

[jsr339-experts] Re: [jax-rs-spec users] Re: Re: InvocationCallback changing?

Marek Potociar 06/28/2012

[jsr339-experts] Re: [jax-rs-spec users] Re: Re: InvocationCallback changing?

Bill Burke 06/28/2012

[jsr339-experts] Re: [jax-rs-spec users] Re: Re: InvocationCallback changing?

Bill Burke 06/28/2012
 
 
Close
loading
Please Confirm
Close