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