Re: [gatein-dev] XML Parsing, where do we stand

and by the way the latest code for staxnav can be found here if you want to have a look at it : https://github.com/vietj/staxnav happy forking

On Feb 24, 2011, at 1:13 PM, Julien Viet wrote: > First of all, the code written only do XML parsing and not writing > (although for writing I have also some good ideas I put in Chromattic > XML writer (but based on DOM instead of stax), but that is not > something I want to impose at the moment :-) ). > > Then for judging a framework I would say that the following criteria > matter: > - performances (i.e the framework should not degrade much performance > of the wrapped stax implementation) > - work with JDK 6 stax implementation (and other implementations as well) > - being expressive and have a good ratio of usefull / boiler plate code > - pass the "portlet.xml" test (because I think it is the most complex > deployment descriptor we have to handle these days) > - wished : it should be part of our codebase to simplify classpath > future classpath problems (given that this will likely part of the > server classpath level). > > Plain stax should offer the best performances (unless it is misused) > however it is not expressive at all because you need to care about > all stax events (specially the end tag events). The code that would > need to be written for parsing portlet.xml correctly would be hard to > write and maintain (i.e fix bugs). > > About "staxnav", I don't think it has draw drawbacks, but that is > purely subjective, so I will leave the critic to others. > > For advantages I consider as valid (maybe I am forgetting some): > > - it allows to write easy to read and maintain code. For about a week > I spend some time rewriting portlet.xml parsing and it made the code > evolve to address the complexity of portlet.xml parsing. > - the codebase remains quite simple and easy to understand > > Julien > > On Feb 24, 2011, at 11:54 AM, Thomas Heute wrote: > >> >> Nick, Julien, Alain, >> >> As said before we'd like to harmonize the XML parsing accross the >> GateIn projects. Let's kill this once for all... >> >> It doesn't mean we would change the existing parsers overnight but >> it means we will impose a way for any new parsing (or when we decide >> to rewrite a parser). >> >> If we need parser tools, they will go in Common module ultimately. >> There might be a phase when the code will be duplicated (as Nick's >> tools need to work on an untouched portal where upgrading common is >> not an option). >> >> We already agreed that StAX as a base was the way to go, I hope we >> still agree ;) >> >> Let's separate in reading/writing XML (doesn't necessarily >> necessarily mean marhalling/unmarshalling BTW) and agree on both. >> >> Reading XML: >> Option 1: >> Plain StAX, JBoss AS 7 uses that (in fact they use StAX >> Mapper, a very lightweight library made by the JBoss AS7 team. >> https://github.com/jbossas/staxmapper/ which only helps to work with >> multiple namespaces + some little helpers for ignoring part of the >> file, format the XML when writing...) >> One example of JBoss AS 7 parsing file: >> https://github.com/emuckenhuber/jboss-as/blob/master/web/src/main/java/or... >> Option 2: >> Nick's stuff (please explain advantages/drawbacks) >> Option 3: >> Julien/Alain's stuff (please explain advantages/drawbacks) >> >> Writing XML: >> Option 1: >> Plain StAX (well-formed guaranteed over plain Writer) >> Option 2: >> Nick's stuff (please explain advantages/drawbacks) >> Option 3: >> Julien/Alain's stuff (please explain advantages/drawbacks) >> >> Note that there are other utilities and frameworks based on StAX: >> Stax-Utils: http://stax-utils.dev.java.net/ >> StaxMate: http://wiki.fasterxml.com/StaxMateHome >> Apache Axiom: http://ws.apache.org/commons/axiom/ >> >> Thomas/ >> / >