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.
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 [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.
