cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <bimargul...@gmail.com>
Subject Re: JAX-RS and generics
Date Sun, 06 Sep 2009 02:15:07 GMT
On Sat, Sep 5, 2009 at 1:57 PM, Benson Margulies <bimargulies@gmail.com>wrote:

> JAX-RS defines two fundamental interfaces: MessageBodyReader<T> and
> MessageBodyWriter<T>, and providers implement.
>
> I claim that GENERIC providers that work for any object (like those
> corresponding to data bindings) should, themselves, be GENERIC, and
> implement MessageBodyX<T>, not MessageBodyX<Object>.
>

Allow me to modulate this claim. I thought about it some more.

If you want to define a class as 'implements MessageBodyX<Object>', fine.
However, the right thing to pass to the Class<T> argument will ALWAYS be
Object.class. If you want to cue in the code to the sort of object in
flight, use the Type argument further down the parameter list.


>
> I claim this because the whole API structure of MessageBodyX assumed this.
> It uses Class<T> in a way that requires constant
> @SupressWarnings("unchecked") if the base is MessageBodyX<Object>.
>
> To put my money where my mouth is, as it were, I implemented this for the
> Aegis providers. When I did this, I discovered that the JAX-RS runtime code
> couldn't handle generic type providers. When the provider type is, say,
>
> AegisElementProvider<Book>
>
> then implemented interface comes up as MessageBodyReader<T>, not
> MessageBodyReader<Book>. So it is a TypeVariable, not a class or a
> ParameterizedType.
>
> I fixed the provider selection code to cope, but I didn't write the
> additionally complex code to look at bounds and insist that if there is a
> bound the type at hand be within it.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message