cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin" <>
Subject RE: JAX-RS and generics
Date Sun, 06 Sep 2009 22:09:28 GMT

I'm concerned it may be not be portable, that is the providers which
work with other JAXRS implementations will end up being unusable in CXF.

You may be right but I've seen the number of providers which implement
MessageBodyX<Object> and then cast them internally. For ex to Feed or
Entry, etc.

Let me ask a question on the jaxrs users list...  
Cheers, Sergey  

-----Original Message-----
From: Benson Margulies [] 
Sent: 06 September 2009 03:15
To: CXF Dev
Subject: Re: JAX-RS and generics

On Sat, Sep 5, 2009 at 1:57 PM, Benson Margulies

> 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>',
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
> 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
> Aegis providers. When I did this, I discovered that the JAX-RS runtime
> couldn't handle generic type providers. When the provider type is,
> 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.

View raw message