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

[Nick Scavelli]

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/org/jboss/as/web/WebSubsystemParser.java

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/gatein-dev/attachments/20110303/69be4007/attachment.html