Return-Path: Delivered-To: apmail-cxf-dev-archive@www.apache.org Received: (qmail 48626 invoked from network); 31 Aug 2009 12:23:13 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 31 Aug 2009 12:23:13 -0000 Received: (qmail 30286 invoked by uid 500); 31 Aug 2009 12:23:12 -0000 Delivered-To: apmail-cxf-dev-archive@cxf.apache.org Received: (qmail 30213 invoked by uid 500); 31 Aug 2009 12:23:12 -0000 Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cxf.apache.org Delivered-To: mailing list dev@cxf.apache.org Received: (qmail 30203 invoked by uid 99); 31 Aug 2009 12:23:12 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 31 Aug 2009 12:23:12 +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; Mon, 31 Aug 2009 12:23:03 +0000 Received: from ntmamx1.progress.com (127.0.0.1) by ntmamx1.progress.com (MlfMTA v3.2r9) id hjf09s0171s3 for ; Mon, 31 Aug 2009 08:22:34 -0400 (envelope-from ) Received: from progress.com ([172.16.3.168]) by ntmamx1.progress.com (SonicWALL 7.1.1.1995) with ESMTP; Mon, 31 Aug 2009 08:22: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 n7VCMg9I008160 for ; Mon, 31 Aug 2009 08:22:42 -0400 (EDT) Received: from MAIL02.bedford.progress.com ([172.16.2.55]) by NTEXFE01.bedford.progress.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Aug 2009 08:22:42 -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: Handling collections with Aegis in JAX-RS Date: Mon, 31 Aug 2009 08:22:40 -0400 Message-ID: In-Reply-To: <61b5d9410908310458l70df52c1wcaf38baa3a547ce2@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Handling collections with Aegis in JAX-RS Thread-Index: AcoqMnw1nLt1Uy8aRF2icqKi9e6RPQAAGl1g From: "Sergey Beryozkin" To: X-OriginalArrivalTime: 31 Aug 2009 12:22:42.0598 (UTC) FILETIME=[BCFF9460:01CA2A35] X-Mlf-Version: 7.1.1.1995 X-Mlf-UniqueId: o200908311222340352173 X-Virus-Checked: Checked by ClamAV on apache.org Hi Benson I'll update the javaDocs, now it is the Map, Type> that will be passed. For example,=20 List updateList(@PathParam("someParam") FooBean param, List bars); In this method a Foo type won't be of interest to Aegis but only List and List. So the map containing : 1. updateListMethod.getReturnType() : updateListMethod.getGenericReturnType() 2. updateListMethod.getParameterTypes()[1] : updateListMethod.getGenericParameterTypes()[1]=20 =20 Will be passed to the databinding So it will provide all the required information. Do you think it will work for Aegis ? I think it should... > Aegis has a perfectly good API for passing in a set of root classes. Why is it better to pass that collection through this property map instead of calling setRootClasses? JAXRS DataBindingProvider is not coded against specific DataBinding implementations, it is only aware of DataBinding interface, so it should work with JAXB/Aegis/SDO and XMLBeans. The idea behind introducing this provider is to let users to use databinding beans as JAXRS provider instances...=20 Cheers, Sergey -----Original Message----- From: Benson Margulies [mailto:bimargulies@gmail.com]=20 Sent: 31 August 2009 12:59 To: dev@cxf.apache.org Subject: Re: Handling collections with Aegis in JAX-RS The more I look at this, the less I understand it. Aegis has a perfectly good API for passing in a set of root classes. Why is it better to pass that collection through this property map instead of calling setRootClasses? So that you can get to the other data bindings the same way? It still won't work for generics. The problem is this. Aegis has a pre-generic concept of root classes, because they are *classes*, not reflection types. Classes don't carry generic information. While Aegis has a default mappings, it won't use it for root types. Root types have to be in the root classes or derived from the service model. My memory isn't good enough to recall how JAXB deals. When a bean has a generic type as a property, the code is using reflection, so it can do generic type processing. So, to get what you want, we'd need to rework your interface to use java.lang.reflect.Type. I'm willing to look into the Aegis-specific angle here for now and see how to add generic roots. I think the new interface needs more thinks. On Mon, Aug 24, 2009 at 8:58 AM, Sergey Beryozkin wrote: > > Hi Benson > > Thanks for spending your time on these tests, and fixing CXF 2401. I was > also able to add few more tests, including the one which writes/reads a > complex Map to/from JSON. > > AegisJSONProvider tries its best for users to avoid setting up a namespace > map manually, but in cases when it does not guess properly the users would > be able to overwrite namespaces and their prefixes as needed. This isssue > would likely arise on the read side only, when CXF reads it. JSON is > namespace-unaware so when reading, one needs to setup a namespace map for > Jettison to report values like @ns1.bar to the JAXB reader... (but only if > AegisJSONProvider has not guessed how to map prefixes to namespaces) > > There's a couple of issues I'd like to discuss. First one is that > AegisJsonProviderTest.testReadWriteComplexMap does have to setup a namespace > for a map root element, but it does not have to do it for > testWrite/ReadCollection tests. I'm wondering, can it be avoided in cases > when Maps are being written/read ? That is, can we modify > createReader/Writer methods such that QNames for containers like > Map/Collections and its member types are available ? > > Another one is that DataBindingJSONProvider test (aegis tests) still can not > handle collections. I think the problem there is that when > DataBindingProvider (the one DataBindingJSONProvider extends) is being > initialized, it uses a workaround which we discussed in the other thread. > Namely, it attempts to convert a JAXRS model info into WSDL-like one and set > calls DataBinding.initialize(Service). It's quite limiting for a number of > reasons, and one of them is that the generic types are not visible to data > bindings.... > So we introduced PropertiesAwareDataBinding interface and I've just updated > the JAXRS code to call it like this : > > Map, Type> allClasses =3D getAllJAXRSResponseInputTypes(); > Map props =3D new HashMap(); > props.put(PropertiesAwareDataBinding.TYPES_PROPERTY, allClasses); > ((PropertiesAwareDataBinding)db).initialize(props); > > At the moment no CXF DataBindings implement this newly introduced interface. > I think the only way for DataBindingJSONProvider aegis tests which handle > collections to start passing is for Aegis DataBinding to implement > PropertiesAwareDataBinding and initialize itself using the provided > Map, Type>, as opposed to Service. Would you be open to updating > the Aegis databinding ? > > thanks, Sergey > > > > > > > > > > > > bimargulies wrote: >> >> I have a rather clear memory of working on these, there wasn't enough >> passing of Generic classes around. I'll go have a look. >> >> >> On Fri, Aug 21, 2009 at 6:38 AM, Sergey >> Beryozkin wrote: >>> >>> Hi Benson >>> >>> if you could look at any of these tests or at least point me in the right >>> direction then it would be great. >>> I know you're busy - so just look at it whenever you get a chance, not >>> urgent... >>> >>> cheers, Sergey >>> >>> >>> Sergey Beryozkin-2 wrote: >>>> >>>> >>>> >>>> Hi Benson >>>> >>>> I can't make the Aegis tests writing/reading collections working in CXF >>>> JAX-RS. >>>> I've found that AegisProviderTest#testReadWriteComplexMap is still >>>> @Ignored, it might've passed for you because it was @Ignored :-) >>>> >>>> I've also added testWriteCollections() (which writes >>>> List) >>>> to AegisJSONProviderTest. I also updated DataBindingJSONProviderTest, >>>> one >>>> of its internal classes to return List. AegisJSONProvider extends >>>> AegisElementProvider, DataBindingJSONProvider extends >>>> DataBindingProvider >>>> which actually (in this case) delegates to Aegis DataBinding. >>>> >>>> AegisJSONProviderTest fails at the write time, it can't find the mapping >>>> for List. DataBindingJSONProviderTest fails early at the Aegis >>>> DataBinding >>>> initialization time for the same reason. I thought Lists were supported >>>> by >>>> default ? I haven't found any exam[le showing how a type mapping for >>>> Lists >>>> can be created. >>>> Can you please, whenever you have a chance, have a look at these tests ? >>>> >>>> thanks, Sergey >>>> >>>> >>> >>> -- >>> View this message in context: >>> http://www.nabble.com/Handling-collections-with-Aegis-in-JAX-RS-tp249331 44p25076146.html >>> Sent from the cxf-dev mailing list archive at Nabble.com. >>> >>> >> >> > > -- > View this message in context: http://www.nabble.com/Handling-collections-with-Aegis-in-JAX-RS-tp249331 44p25115676.html > Sent from the cxf-dev mailing list archive at Nabble.com. > >