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

[Julien Viet]

On Mar 9, 2011, at 12:16 PM, Thomas Heute wrote:

> So the decision is to use StaxNav for any XML parsing done with GateIn projects (again, there is no need to convert the existing, I'm talking about new parsers).
> 

indeed, Alain is working on it a bit this week to add testing with the various stax impl available in addition of the JDK one. The goal is that it works the same with the various impls.

> StaxNav will be delivered as a thirdparty library (soon to be available on Maven central repo).

I will ask Arnaud to review the POM and configure the sync with Maven Central once Alain has finished to rework the pom.

> 
> For the writing part (which is less of an issue and also less used), this isn't yet fully defined.
> 
> Thomas
> 
> 
> 
> On 03/03/2011 04:35 PM, Nick Scavelli wrote:
>> 
>> 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/20110309/b9852b50/attachment.html