Hi, As I said in the other email, JSON has no idea of what namespaces are so some mapping between namespaces and prefixes has to exist. We can also instruct Jettison to drop namespaces alltogether - if users would like to use some JSON utilities and parse JSON sequences without worrying about what 'ns1.' is. Perhaps Jettison can be enhanced to create keys on the fly.
I'd like to clarify why I'd like users be able to build JSON on top of Aegis or SDO or XMLBeans. It is about being able to preserve their 'investments' into a given databinding technology. Many users won't deal with List<List<Map<Bar>> return/input types. It will be plain beans, may be with some moderate complexity - it's better after all to have beans as opposed to explicit collections simply because they can be better described in WADL for ex, etc. For users who prefer to deal with advanced collections and who have invested in dealing with Aegis for ex, it might be advanatgeous to let them tell the JAXRS runtime to do JSON on top of Aegis, without having to bring extra dependencies like Jackson. And I believe some users have actually wrapped Jackson in their custom providers - perhaps I might just add a system test showing how Jackson can be wrapped. cheers, Sergey ----- Original Message ----- From: Benson Margulies To: CXF Dev ; Sergey Beryozkin Sent: Saturday, September 05, 2009 2:41 PM Subject: Aegis + JSON = Chaos in namespaces I've convinced myself that the implementation of aegis+json for JAX-RS, with respect to namespaces, has absolutely got to change. Let me lay out the situation as I see it. When we are writing XML, Aegis assigns prefixes on the fly, though it will respect a map of preferred prefixes. These prefixes are fed to StaX, incrementally, and all is well. The Jettison implementation of the StaX API is badly crippled with respect to namespaces. It ignores setPrefix, and will throw an unchecked exception in the presence of any namespace that is not defined, in advanced, in the 'Convention' object. In my tree at the moment, I've gotten around this by subclassing the Jettison MappedXMLStreamWriter and handling the exception and respecting the available prefix. However, this only moves the problem down the pipe. It would be cleaner to write, say, a DOM tree, then collect all the prefixes, and then put them in Jettison's stupid map, and then copy from the DOM tree to Jettison. Slower but cleaner. The result of all of this is json that has undefined namespace prefixes. The json keys just look like 'ns1.HereIsMyObject'. Nothing is written to in the JSON that defines what namespace 'ns1' is. Instead, the code sort of takes it on faith that 'ns1' will be the prefix for the top-level element, and defines no other prefixes. The code to derive that namespace is wrong, and I can fix it, but that won't make the unbounded collection of other prefixes for other schema appear by magic. Part of the problem here is that the flags to write XSI types are turned off, at least in the test case I'm working with. Still, I don't see how it can be interoperable to write out these prefixes without definitions if we expect to get them back.
