On Mon, Sep 7, 2009 at 1:20 PM, Sergey Beryozkin <[email protected]>wrote:
> > Hi > > [1] +1 to b. yes it does, I haven't tried but users can wrap whatever > providers they want into their custom JAXRS providers. I'd rather do a > system test showing users they can do if they want. > I did the systest. If you think more testing is called for, let me know what. > > possible pros : jackson will do natural JSON easily > possible cons : it's convention-based, that is it thinks that json has to > follow the natural convention; and having Aegis users who are working with > Map/List based interfaces to download jackson seems a bit harsh - in OSGI > they'll also need to install another bundle > Let's see what we hear from the users list about these Aegis users. > > [3] +1 to 'unqualified' Aegis for JSON but only when users have asked for > it. I think it is a better solution than bringing a new dependency to CXF. > Basically, if users are working with existing CXF DataBindings then they > should be given an option to use then for creating JSON. So > DataBindingJSONProvider can be told to produce 'unqualified' JSON in all > cases (for Aegis, SDO, XMLBeans, etc). Not sure how it will work for cases > when derived types are returned when Base is expected.... > > Sergey > > > bimargulies wrote: > > > > I am hoping to attract some comments from other members of the community > > by > > gathering a few threads of debate between Sergey and myself in one place. > > If > > I misrepresent his side of these arguments I'm sure he'll let me know. I > > also plan to ask some questions on the user list. > > > > [1] The default JSON provider. > > > > I've been comparing the Jackson JSON provider to the JSONProvider in CXF. > > I > > see three possibilities: > > > > [a] Deprecate ours in favor of theirs > > [b] Document the fact that Jackson works with CXF and write up the > > tradeoffs. > > [c] Do nothing. > > > > I would like to see us at least take door [b]. Our JSONProvider has some > > issues: it consists of a combination of JAXB and Jettison. The latter has > > bugs that keep coming up. The former poses issues for some users, or so I > > am > > told. Jackson has some advantages, I think. The most notable is an > > annotation model that is small and straightforward for JSON production > and > > consumptin. > > > > [2] The role of data binding providers. > > > > I can see why users would find a lot of value in the data binding > > providers > > when their content type is XML. The existing data bindings are all in the > > XML business; their various controls and options are all relevant. Work > > users put into setting them up is largely relevant, it not always > > sufficient > > (e.g. @XmlRootElement requirements). However, I think that there are > > caveats > > that deserve discussion in our documentation. Marking a transient > property > > to be ignore, that's good all around. A production schema, on the other > > hand, may well have XML constructs that are not friendly to some sort of > > simple Javascript client. > > > > When we get to JSON, however, I'm much more skeptical. Even without the > > various bugs encountered in Jettison, the JSON you get when you push a > > complex pile of XML into Jettison is pretty convoluted. I offer a sort of > > a > > reduction argument: if the interface is a simple one, then no one needs a > > complex data binding, and if it is a complex one, expecting to use what > > comes out of the data binding + Jettison is likely to run into trouble. > > > > I'm not proposing to delete any code here, just to set expectations. > > > > [3] The role of Aegis in all of this > > > > Aegis has turned into a central point in these issues for several > reasons. > > First, we put effort into making Aegis work with JAX-RS, so that people > > who > > wanted to avoid JAXB had an alternative. Then we noticed that Aegis > always > > produces 'qualified' schemas. Then we noticed that Jettison's model of > > namespace management doesn't work for this purpose. It requires a static > > mapping of namespaces to prefixes, rather than a dynamic mapping as in > XML > > itself. > > > > So, my view is that we should push Jackson as a solution to a JAXB-less > > mapping from Java to and from JSON. The alternative would be to invent > > 'unqualified' Aegis. (a) I don't know if I have time, (b) I fear that it > > will only expose a next layer of things people don't like, like the extra > > layer of elements in Aegis maps. Sergey is unpersuaded. Anybody else care > > to > > toss an opinion into the right? > > > > If someone else wants to jump on an option to make Aegis unqualified, > > don't > > think for a moment that I'll protest. > > > > > > -- > View this message in context: > http://www.nabble.com/Restating-some-JAX-RS-debates-tp25329761p25333768.html > Sent from the cxf-dev mailing list archive at Nabble.com. > >
