On Fri, Mar 9, 2012 at 5:21 PM, Denis Gervalle <[email protected]> wrote: > On Fri, Mar 9, 2012 at 17:17, Jerome Velociter <[email protected]>wrote: > >> On Fri, Mar 9, 2012 at 4:51 PM, Denis Gervalle <[email protected]> wrote: >> > On Fri, Mar 9, 2012 at 16:08, Marius Dumitru Florea < >> > [email protected]> wrote: >> > >> >> On Fri, Mar 9, 2012 at 4:47 PM, Jerome Velociter <[email protected] >> > >> >> wrote: >> >> > On Fri, Mar 9, 2012 at 3:26 PM, Marius Dumitru Florea >> >> > <[email protected]> wrote: >> >> >> On Fri, Mar 9, 2012 at 4:10 PM, Vincent Massol <[email protected]> >> >> wrote: >> >> >>> >> >> >>> On Mar 9, 2012, at 3:02 PM, Denis Gervalle wrote: >> >> >>> >> >> >>>> On Fri, Mar 9, 2012 at 14:54, Marius Dumitru Florea < >> >> >>>> [email protected]> wrote: >> >> >>>> >> >> >>>>> Hi devs, >> >> >>>>> >> >> >>>>> Some time ago Jerome Velociter raised a vote [1] for adding a JSON >> >> >>>>> Velocity Tool. The vote passed but the tool wasn't committed. I'd >> >> like >> >> >>>>> to do it know (for 4.0M1) with two changes: >> >> >>>>> >> >> >>>>> 1. Use Jackson [2] instead of json-lib [3] because it has a more >> >> recent >> >> >>>>> release >> >> >>>>> >> >> >>>> >> >> >>>> Isn't json-lib already a dependency available, should we use >> another >> >> one ? >> >> >>> >> >> >>> +1 to use only one json lib in xwiki! :) >> >> >> >> >> >> Fine.. since json-lib is already used in public API >> >> >> (com.xpn.xwiki.plugin.packaging.PackageAPI) I'll stick with it. >> >> > >> >> > Jackson is considered faster, by several orders. Some articles/threads >> >> > that talks about it : >> >> > - >> >> >> http://www.lshift.net/blog/2011/12/28/benchmarking-simple-json-generation-in-java >> >> > - http://www.sencha.com/forum/archive/index.php/t-94883.html >> >> > >> >> >> >> > It can be a case for Jackson : if we are to use that tool for >> >> > generating livetable values, performance is a big deal. >> >> >> >> That's my use case. I want to refactor the macros from >> >> XWiki.LiveTableResultsMacros to generate the "JSON" in memory (using >> >> actually plain Java data types like maps and lists/arrays) so that I >> >> can adjust it before the response is send to the client. This way I >> >> can avoid duplicating the code from XWiki.LiveTableResultsMacros just >> >> to add a new property to the generated JSON or to modify the value of >> >> an existing property. >> >> >> >> Since json-lib is used only in xwiki-platform-oldcore by the package >> >> plugin I think it's fine to: >> >> >> >> * use Jackson in JSONTool >> >> * when we refactor the package plugin into a component (if we still >> >> needed it at that point) we can also change the code to use Jackson. I >> >> can add a comment in the pom for this so that we don't forget about >> >> it. >> >> >> >> WDYT? >> >> >> > >> > What about groovy ? the JSONBuilder provided by json-lib is nice to have, >> > and is one of the motivation of the initial thread. >> > I am not asking for annoying you, we use all that already in many sites. >> I >> > am not against improving, but we should also be careful to not break >> > existing stuffs. >> >> I'm not sure what's the problem/how groovy changes the picture here. >> Right now json-lib is bundled with XWiki and used internally, but not >> exposed. I don't think bundled jars should be assumed stable over >> time. Do we have a rule for this ? >> >> In any case that's not good enough a reason to ditch jackson in favor >> of json-lib, IMHO. Worse case, it's an argument in favor of keeping >> json-lib in the classpath in addition to whatever other lib we decide >> to use - should we decide to use something else than json-lib. >> > > That was my concern, you expressed yourself better than I have. > The question is simply, is Jackson so much better that we want to have > both, or drop some compatibility.
Personnally I don't have too strong feelings, however, I think that : * Good performance of the livetable is important. JSON serialization time might not be that much a big deal compared to SQL time - but in the end once you got rid of big bottlenecks, the performance of every link in the chain matters. * There is support for jackson in Restlet via an extension. This could help us improve performance of our REST API for JSON payloads/responses. * Jackson seems more active So in the end I tend to be in favor of jackson over json-lib. There is also GSON that could be investigated. Personnally I've never worked with it/don't know much about it. Jerome > > >> >> > >> > >> >> >> >> I'm +1 for this. >> >> >> >> Thanks, >> >> Marius >> >> >> >> > >> >> > my 2 cents >> >> > >> >> > Jerome >> >> > >> >> > >> >> >> >> >> >> Thanks, >> >> >> Marius >> >> >> >> >> >>> >> >> >>> Thanks >> >> >>> -Vincent >> >> >>>> >> >> >>>> >> >> >>>>> 2. Add only the toJSON method for now because we can use >> >> >>>>> $escapetool.javascript to accomplish the same result as >> toValueString >> >> >>>>> >> >> >>>>> Reply quickly if you are against it. >> >> >>>>> >> >> >>>>> Thanks, >> >> >>>>> Marius >> >> >>>>> >> >> >>>>> [1] http://www.mail-archive.com/[email protected]/msg11395.html >> >> >>>>> [2] http://jackson.codehaus.org/ >> >> >>>>> [3] http://json-lib.sourceforge.net/ >> >> >>> _______________________________________________ >> >> >>> devs mailing list >> >> >>> [email protected] >> >> >>> http://lists.xwiki.org/mailman/listinfo/devs >> >> >> _______________________________________________ >> >> >> devs mailing list >> >> >> [email protected] >> >> >> http://lists.xwiki.org/mailman/listinfo/devs >> >> > >> >> > >> >> > -- >> >> > Jérôme Velociter >> >> > Winesquare >> >> > http://www.winesquare.net/ >> >> > _______________________________________________ >> >> > devs mailing list >> >> > [email protected] >> >> > http://lists.xwiki.org/mailman/listinfo/devs >> >> _______________________________________________ >> >> devs mailing list >> >> [email protected] >> >> http://lists.xwiki.org/mailman/listinfo/devs >> >> >> > >> > >> > >> > -- >> > Denis Gervalle >> > SOFTEC sa - CEO >> > eGuilde sarl - CTO >> > _______________________________________________ >> > devs mailing list >> > [email protected] >> > http://lists.xwiki.org/mailman/listinfo/devs >> >> >> >> -- >> Jérôme Velociter >> Winesquare >> http://www.winesquare.net/ >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs >> > > > > -- > Denis Gervalle > SOFTEC sa - CEO > eGuilde sarl - CTO > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs -- Jérôme Velociter Winesquare http://www.winesquare.net/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
