There are two ways to look at this. From the point of view of a 'provider bean', I can believe that a non-generic class is attractive. Maybe essential. Maybe my change to the Aegis providers was thus a mistake.
>From the point of view of a clean API callable without suppressing any warnings, on the other hand, the generic nature of the JAX-RS APIs makes them ugly to reduce to non-generic types. On Sun, Sep 6, 2009 at 6:09 PM, Sergey Beryozkin <sbery...@progress.com>wrote: > Hi > > 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 [mailto:bimargul...@gmail.com] > 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 > <bimargul...@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. > > >
