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 :-) ). Then for judging a framework I would say that the following criteria matter: - performances (i.e the framework should not degrade much performance of the wrapped stax implementation) - work with JDK 6 stax implementation (and other implementations as well) - being expressive and have a good ratio of usefull / boiler plate code - pass the "portlet.xml" test (because I think it is the most complex deployment descriptor we have to handle these days) - 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). 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). About "staxnav", I don't think it has draw drawbacks, but that is purely subjective, so I will leave the critic to others. For advantages I consider as valid (maybe I am forgetting some): - 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. - the codebase remains quite simple and easy to understand Julien On Feb 24, 2011, at 11: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 ;) > > 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/or... > Option 2: > Nick's stuff (please explain advantages/drawbacks) > Option 3: > Julien/Alain's stuff (please explain advantages/drawbacks) > > Writing XML: > Option 1: > Plain StAX (well-formed guaranteed over plain Writer) > Option 2: > Nick's stuff (please explain advantages/drawbacks) > Option 3: > Julien/Alain's stuff (please explain advantages/drawbacks) > > 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

On 02/24/2011 08:13 AM, Julien Viet wrote: > > and by the way the latest code for staxnav can be found here if you want to have a look at it : https://github.com/vietj/staxnav > > happy forking 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. - Nick > > > On Feb 24, 2011, at 1:13 PM, Julien Viet wrote: > >> 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 :-) ). >> >> Then for judging a framework I would say that the following criteria matter: >> - performances (i.e the framework should not degrade much performance of the wrapped stax implementation) >> - work with JDK 6 stax implementation (and other implementations as well) >> - being expressive and have a good ratio of usefull / boiler plate code >> - pass the "portlet.xml" test (because I think it is the most complex deployment descriptor we have to handle these days) >> - 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). >> >> 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). >> >> About "staxnav", I don't think it has draw drawbacks, but that is purely subjective, so I will leave the critic to others. >> >> For advantages I consider as valid (maybe I am forgetting some): >> >> - 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. >> - the codebase remains quite simple and easy to understand >> >> Julien >> >> On Feb 24, 2011, at 11: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 ;) >>> >>> 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/or... >>> Option 2: >>> Nick's stuff (please explain advantages/drawbacks) >>> Option 3: >>> Julien/Alain's stuff (please explain advantages/drawbacks) >>> >>> Writing XML: >>> Option 1: >>> Plain StAX (well-formed guaranteed over plain Writer) >>> Option 2: >>> Nick's stuff (please explain advantages/drawbacks) >>> Option 3: >>> Julien/Alain's stuff (please explain advantages/drawbacks) >>> >>> 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 >> >

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/or... 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