Return-Path: 
 <dev-return-8305-apmail-cxf-dev-archive=cxf.apache.org@cxf.apache.org>
Delivered-To: apmail-cxf-dev-archive@www.apache.org
Received: (qmail 10731 invoked from network); 6 Sep 2009 22:10:17 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3)
  by minotaur.apache.org with SMTP; 6 Sep 2009 22:10:17 -0000
Received: (qmail 71875 invoked by uid 500); 6 Sep 2009 22:10:16 -0000
Delivered-To: apmail-cxf-dev-archive@cxf.apache.org
Received: (qmail 71816 invoked by uid 500); 6 Sep 2009 22:10:16 -0000
Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@cxf.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@cxf.apache.org>
List-Post: <mailto:dev@cxf.apache.org>
List-Id: <dev.cxf.apache.org>
Reply-To: dev@cxf.apache.org
Delivered-To: mailing list dev@cxf.apache.org
Received: (qmail 71806 invoked by uid 99); 6 Sep 2009 22:10:16 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 06 Sep 2009 22:10:16 +0000
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: local policy)
Received: from [131.239.30.131] (HELO ntmamx1.progress.com) (131.239.30.131)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 06 Sep 2009 22:10:08 +0000
Received: from ntmamx1.progress.com (127.0.0.1) by ntmamx1.progress.com
 (MlfMTA v3.2r9) id hkgpk80171sb for <dev@cxf.apache.org>;
 Sun, 6 Sep 2009 18:09:34 -0400 (envelope-from <sberyozk@progress.com>)
Received: from progress.com ([172.16.3.168])
	by ntmamx1.progress.com (SonicWALL 7.1.1.1995)
	with ESMTP; Sun, 06 Sep 2009 18:09:34 -0400
Received: from NTEXFE01.bedford.progress.com (ntexfe01 [10.128.10.24])
	by progress.com (8.13.8/8.13.8) with ESMTP id n86M9U1A013681
	for <dev@cxf.apache.org>; Sun, 6 Sep 2009 18:09:30 -0400 (EDT)
Received: from MAIL02.bedford.progress.com ([172.16.2.55]) by
 NTEXFE01.bedford.progress.com with Microsoft SMTPSVC(6.0.3790.3959);
	 Sun, 6 Sep 2009 18:09:29 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: JAX-RS and generics
Date: Sun, 6 Sep 2009 18:09:28 -0400
Message-ID: 
 <D9D39D1E52C5514C94DE9B5E928C72DB033F70EC@MAIL02.bedford.progress.com>
In-Reply-To: <61b5d9410909051915y6ef90f44o886b71867c2cae28@mail.gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: JAX-RS and generics
Thread-Index: Acoul+4S3mGOhOWOTQmZtcqz1RttLAApWpcg
From: "Sergey Beryozkin" <sberyozk@progress.com>
To: <dev@cxf.apache.org>
X-OriginalArrivalTime: 06 Sep 2009 22:09:29.0774 (UTC)
 FILETIME=[B496CCE0:01CA2F3E]
X-Mlf-Version: 7.1.1.1995
X-Mlf-UniqueId: o200909062209340322816
X-Virus-Checked: Checked by ClamAV on apache.org

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... =20
Cheers, Sergey =20

-----Original Message-----
From: Benson Margulies [mailto:bimargulies@gmail.com]=20
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
<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.
>