Sergey, I've made it as far as the namespace issues with JSON, since the changes I've made to deal with generic types have made them worse.
There's something here that I just don't follow. When the output is XML, all the namespaces just take care of themselves. Aegis assigns prefixes and StaX writes them. Admittedly, if Aegis ever forgot to assign a prefix StaX would just go add an xmlns=, but I don't (yet) think that this is something that happens. Do you have any idea why the JSON environment ends up being so much more fussy? --benson On Mon, Aug 24, 2009 at 8:58 AM, Sergey Beryozkin <sergey.beryoz...@iona.com > 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<Class<?>, Type> allClasses = getAllJAXRSResponseInputTypes(); > Map<String, Object> props = new HashMap<String, Object>(); > 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<Class<?>, 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<sergey.beryoz...@iona.com> 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<AegisTestBean>) > >>> to AegisJSONProviderTest. I also updated DataBindingJSONProviderTest, > >>> one > >>> of its internal classes to return List<Book>. 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-tp24933144p25076146.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-tp24933144p25115676.html > Sent from the cxf-dev mailing list archive at Nabble.com. > >
