<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div><div><div>On Mar 9, 2011, at 12:16 PM, Thomas Heute wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<div bgcolor="#ffffff" text="#000000">
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).<br>
<br></div></blockquote><div><br></div><div>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.</div><br><blockquote type="cite"><div bgcolor="#ffffff" text="#000000">
StaxNav will be delivered as a thirdparty library (soon to be
available on Maven central repo).<br></div></blockquote><div><br></div><div>I will ask Arnaud to review the POM and configure the sync with Maven Central once Alain has finished to rework the pom.</div><br><blockquote type="cite"><div bgcolor="#ffffff" text="#000000">
<br>
For the writing part (which is less of an issue and also less used),
this isn't yet fully defined.<br>
<br>
Thomas<br>
<br>
<br>
<br>
On 03/03/2011 04:35 PM, Nick Scavelli wrote:
<blockquote cite="mid:4D6FB535.3040301@redhat.com" type="cite">
On 02/24/2011 05:54 AM, Thomas Heute wrote:
<blockquote cite="mid:4D6638F0.40703@redhat.com" type="cite">
<br>
Nick, Julien, Alain,<br>
<br>
As said before we'd like to harmonize the XML parsing accross
the GateIn projects. Let's kill this once for all...<br>
<br>
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).<br>
<br>
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).<br>
<br>
We already agreed that StAX as a base was the way to go, I hope
we still agree ;)<br>
</blockquote>
<br>
I think we're in agreement that StAX is the way to go if we're
focusing on pure performance.<br>
<br>
<blockquote cite="mid:4D6638F0.40703@redhat.com" type="cite"> <br>
Let's separate in reading/writing XML (doesn't necessarily
necessarily mean marhalling/unmarshalling BTW) and agree on
both.<br>
<br>
Reading XML:<br>
Option 1:<br>
Plain StAX, JBoss AS 7 uses that (in fact they use StAX
Mapper, a very lightweight library made by the JBoss AS7 team. <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://github.com/jbossas/staxmapper/">https://github.com/jbossas/staxmapper/</a>
which only helps to work with multiple namespaces + some little
helpers for ignoring part of the file, format the XML when
writing...)<br>
One example of JBoss AS 7 parsing file: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://github.com/emuckenhuber/jboss-as/blob/master/web/src/main/java/org/jboss/as/web/WebSubsystemParser.java">https://github.com/emuckenhuber/jboss-as/blob/master/web/src/main/java/org/jboss/as/web/WebSubsystemParser.java</a><br>
</blockquote>
<br>
Since we've already invested some time to write some code around
stax, I think we agree on something that will benefit GateIn.<br>
<br>
<blockquote cite="mid:4D6638F0.40703@redhat.com" type="cite">
Option 2:<br>
Nick's stuff (please explain advantages/drawbacks)<br>
</blockquote>
<br>
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.<br>
<br>
<blockquote cite="mid:4D6638F0.40703@redhat.com" type="cite">
Option 3:<br>
Julien/Alain's stuff (please explain
advantages/drawbacks)<br>
</blockquote>
<br>
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.<br>
<br>
<blockquote cite="mid:4D6638F0.40703@redhat.com" type="cite"> <br>
Writing XML:<br>
Option 1:<br>
Plain StAX (well-formed guaranteed over plain Writer)<br>
Option 2:<br>
Nick's stuff (please explain advantages/drawbacks)<br>
</blockquote>
<br>
Has formatting writer, can chain writes, easy to use.<br>
<br>
<blockquote cite="mid:4D6638F0.40703@redhat.com" type="cite">
Option 3:<br>
Julien/Alain's stuff (please explain
advantages/drawbacks)<br>
</blockquote>
<br>
No writing capabilities.<br>
<blockquote cite="mid:4D6638F0.40703@redhat.com" type="cite"> <br>
Note that there are other utilities and frameworks based on
StAX:<br>
Stax-Utils: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://stax-utils.dev.java.net/">http://stax-utils.dev.java.net/</a><br>
StaxMate: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://wiki.fasterxml.com/StaxMateHome">http://wiki.fasterxml.com/StaxMateHome</a><br>
Apache Axiom: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://ws.apache.org/commons/axiom/">http://ws.apache.org/commons/axiom/</a><br>
<br>
Thomas<i><br>
</i> </blockquote>
<br>
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.<br>
<br>
- Nick<br>
<br>
</blockquote>
<br>
</div>
</blockquote></div><br></div></body></html>