cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin" <>
Subject Re: Aegis + JSON = Chaos in namespaces
Date Mon, 07 Sep 2009 09:18:17 GMT

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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message