How about dropping the namespaces from the produced JSON ? A simple wrapper around XMLStreamWriter woud do it. And Jettison can produce natural JSONs too (some configuration is needed for that)
As I said in the other email, some users may've invested in Aegis already. So suppose they have a method which returns Map<String, Book> how would Jackson serialize it in this case, and how would Aegis + JSON do it ? I'm not a JSON expert and I haven't tried Jackson but I'm nearly sure Aegis will do pretty well here too (especially an 'unqualified' one) I'd be keen on Aegis + JSON working for this reason : let Aegis users output their explicit collections in JSON. I'm not thinking of presenting Aegis+JSON as the best CXF JSON offer. So, I'd say it's your call. Sergey bimargulies wrote: > > Sergey, > > Fine when producing JSON, albeit very ugly JSON. Completely impractical > when > reading the stuff. I can see no way to make it work in a live application. > I > also can't see why anyone would want this, as compared to what comes out > of > the Jackson provider. Which can be tuned with annotations, etc, etc. > > --benson > > > On Sun, Sep 6, 2009 at 5:58 PM, Sergey Beryozkin > <sergey.beryoz...@iona.com>wrote: > >> >> Hi Benson >> >> JSON has no idea of what namespaces so it needs to map namespaces to >> something, hence the need for >> a namespace map being setup. In simple cases it's now being done >> automatically... >> >> cheers, Sergey >> >> >> bimargulies wrote: >> > >> > 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. >> >> >> >> >> > >> > >> >> -- >> View this message in context: >> http://www.nabble.com/Handling-collections-with-Aegis-in-JAX-RS-tp24933144p25322525.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-tp24933144p25327725.html Sent from the cxf-dev mailing list archive at Nabble.com.
