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

On 02/24/2011 05: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 ;) I think we're in agreement that StAX is the way to go if we're focusing on pure performance. > > 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... Since we've already invested some time to write some code around stax, I think we agree on something that will benefit GateIn. > Option 2: > Nick's stuff (please explain advantages/drawbacks) The API isn't quite intuitive. Once you get used to it, it's fairly easy to write and maintain. A lot of the use cases that stax-builder provided (reading wise) I think are supported in staxnav, which has a simplified API. I'm good scratching this (reader part) especially if we can solve the issue I mention below about staxnav. > Option 3: > Julien/Alain's stuff (please explain advantages/drawbacks) API is nice to use, makes sense for most xml parsing. One issue I have is that it does save content in memory, even after navigation is successful. I propose we discard all history after a successful navigation. I'll look into a solution for this. > > Writing XML: > Option 1: > Plain StAX (well-formed guaranteed over plain Writer) > Option 2: > Nick's stuff (please explain advantages/drawbacks) Has formatting writer, can chain writes, easy to use. > Option 3: > Julien/Alain's stuff (please explain advantages/drawbacks) No writing capabilities. > > 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/ > / So to summarize, I am leaning towards combining these efforts as we've previously mentioned as long as we don't introduce any performance or maintenance issues as opposed to using plain stax. - Nick