cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sergey.beryoz...@iona.com>
Subject Re: Aegis + JSON = Chaos in namespaces
Date Tue, 08 Sep 2009 16:55:22 GMT

Hi Benson

I've seen your prefix spy writer in the AegisJSONProvider, it's pretty
useful.
I'm also quite happy with simple collections like List<AegisBean> being
handled by AegisJSONProvider.

Now, I've added few simple tests to AegisJSONProviderTest and added an
optional 'ignoreNamespaces' property to JAXB-based JSONProvider,
AegisJSONProvider and DataBindingJSONProvider.

So here's the result. Given the list of two AegisBeans, List<AegisBean>,
here's what is produced (I'm doing pretty-printing here, not Jettison :-)).

1. Default output :

{"ns1.ArrayOfAegisTestBean":
    {
      "@xsi.type":"ns1:ArrayOfAegisTestBean","ns1.AegisTestBean":
      [
         {"@xsi.type":"ns1:AegisTestBean","ns1.boolValue":true,
"ns1.strValue":"hovercraft"},
         {"@xsi.type":"ns1:AegisTestBean",
"ns1.boolValue":true,"ns1.strValue":"hovercraft2"}
      ]
    }
}

Pros : difficult to read and tricky to parse manually
Cons : Client API can be used to read such JSONs and test the service

2. Provider has been configured to ignore xsi:type attributes
 
{"ns1.ArrayOfAegisTestBean":
    {
      "ns1.AegisTestBean":
      [
         {"ns1.boolValue":true, "ns1.strValue":"hovercraft"},
         {"ns1.boolValue":true,"ns1.strValue":"hovercraft2"}
      ]
    }
}

pros : Easy to read and quite easy to parse manually
cons : can't be read with the client api (for Aegis at least)

3. Provider is asked to drop the namespaces

{"ArrayOfAegisTestBean":
    {
      "AegisTestBean":
      [
         {"boolValue":true, "strValue":"hovercraft"},
         {"boolValue":true,"strValue":"hovercraft2"}
      ]
    }
}

Pros : easy to read and parse manually
cons : can't be read with the client api (except for JAXB where
XMLRootElement has only a localname)

4. Provider is asked to drop the namespaces and the root element

    {
      "AegisTestBean":
      [
         {"boolValue":true, "strValue":"hovercraft"},
         {"boolValue":true,"strValue":"hovercraft2"}
      ]
    }


The flexibility is there and DataBindingJSONProvider will be able to do it
for SDO and XMLBeans too.

Will some users think Jackson is simpler/better ? No problems. But I'm
pretty sure in a number of cases there won't be a need for bringing in
Jackson for those users who are already working with CXF DataBindings

Now, as far as Aegis is concerned, I'm quite happy what is there now with
respect to the JSON support. I'd be even happier if one more update were
applied from your side : Implement PropertiesAwareDataBinding such that
DataBindingJSONProvider could be able to wrap Aegis DataBindings and support
simple collections only...Would it be difficult to do ? 


cheers, Sergey


Sergey Beryozkin-2 wrote:
> 
> 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.
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Aegis-%2B-JSON-%3D-Chaos-in-namespaces-tp25308567p25350068.html
Sent from the cxf-dev mailing list archive at Nabble.com.


Mime
View raw message