<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
On 02/24/2011 08:13 AM, Julien Viet wrote:
<blockquote
cite="mid:64A1EF9D-0D16-4855-9497-8A504E2D62F3@julienviet.com"
type="cite">and by the way the latest code for staxnav can be
found here if you want to have a look at it : <a
moz-do-not-send="true" href="https://github.com/vietj/staxnav">https://github.com/vietj/staxnav</a>
<div><br>
</div>
<div>happy forking<br>
</div>
</blockquote>
<br>
This staxnav version seems to solve the issues I previously had with
staxnav. I'll see how this fits with some of the parsing I have
done already. Some preliminary testing seems to support most of
what I want to do, especially the fork method.<br>
<br>
- Nick<br>
<blockquote
cite="mid:64A1EF9D-0D16-4855-9497-8A504E2D62F3@julienviet.com"
type="cite">
<div>
<div><br>
</div>
<div><br>
<div>
<div>On Feb 24, 2011, at 1:13 PM, Julien Viet wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div style="word-wrap: break-word;">
<div>First of all, the code written only do XML parsing
and not writing (although for writing I have also some
good ideas I put in Chromattic XML writer (but based
on DOM instead of stax), but that is not something I
want to impose at the moment :-) ).
<div><br>
</div>
<div>Then for judging a framework I would say that the
following criteria matter:</div>
<div>- performances (i.e the framework should not
degrade much performance of the wrapped stax
implementation)</div>
<div>- work with JDK 6 stax implementation (and other
implementations as well)</div>
<div>- being expressive and have a good ratio of
usefull / boiler plate code</div>
<div>- pass the "portlet.xml" test (because I think it
is the most complex deployment descriptor we have to
handle these days)</div>
<div>- wished : it should be part of our codebase to
simplify classpath future classpath problems (given
that this will likely part of the server classpath
level).</div>
<div><br>
</div>
<div>Plain stax should offer the best performances
(unless it is misused) however it is not expressive
at all because you need to care about all stax
events (specially the end tag events). The code that
would need to be written for parsing portlet.xml
correctly would be hard to write and maintain (i.e
fix bugs).</div>
<div><br>
</div>
<div>About "staxnav", I don't think it has
draw drawbacks, but that is purely subjective, so I
will leave the critic to others.</div>
<div><br>
</div>
<div>For advantages I consider as valid (maybe I am
forgetting some):</div>
<div><br>
</div>
<div>- it allows to write easy to read and maintain
code. For about a week I spend some time rewriting
portlet.xml parsing and it made the code evolve to
address the complexity of portlet.xml parsing.</div>
<div>- the codebase remains quite simple and easy to
understand</div>
<div><br>
</div>
<div>Julien</div>
<div><br>
</div>
<div>
<div>
<div>On Feb 24, 2011, at 11:54 AM, Thomas Heute
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div bgcolor="#ffffff" text="#000000"> <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>
<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>
Option 2:<br>
Nick's stuff (please explain
advantages/drawbacks)<br>
Option 3:<br>
Julien/Alain's stuff (please explain
advantages/drawbacks)<br>
<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>
Option 3:<br>
Julien/Alain's stuff (please explain
advantages/drawbacks)<br>
<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> </div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
</body>
</html>