tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Venkata Krishnan" <for.svkr...@gmail.com>
Subject Re: Using StAX-based loaders for SCDL? was: SCDL4J
Date Tue, 03 Apr 2007 08:00:18 GMT
Hi,

>From what is mentioned here, I'd go with the StAX approach.  Also, Woodstox
seems to be an option for now and would be gone when we move to Java6 which
I suppose we will in the near future.  Is that right?

Thanks

- Venkat

On 4/2/07, Raymond Feng <enjoyjava@gmail.com> wrote:
>
> +1.
>
> Thanks,
> Raymond
>
> ----- Original Message -----
> From: "Jean-Sebastien Delfino" <jsdelfino@apache.org>
> To: <tuscany-dev@ws.apache.org>
> Sent: Saturday, March 31, 2007 9:58 PM
> Subject: Using StAX-based loaders for SCDL? was: SCDL4J
>
>
> > [snip]
> > Raymond Feng wrote:
> >> Hi,
> >>
> >> FYI: I checked in the first cut of the StAX-based loaders under
> >> scdl4j/stax. The logic is very similar to the SAX handlers.
> >>
> >> Thanks,
> >> Raymond
> >>
> >
> > Thanks Raymond, your new StAX loaders look good to me! actually better
> > than the SAX handlers that I had checked in yesterday :)
> >
> > I made a few minor changes to bring them to the same level of
> > functionality as the SAX handlers, and then did a quick comparison
> > between the two approaches.
> >
> > Performance:
> > Here are some numbers from the SAXPerfTest and StAXPerfTest programs
> > that I committed today, which load the same composite file using both
> > techniques.
> > - SAX handler using the JDK parser (Xerces): 0.395 msec
> > - SAX handler using the Woodstox parser: 0.260 msec
> > - StAX reader using the Woodstox parser: 0.258 msec
> > Memory usage is slightly lower with StAX/Woodstox.
> > So StAX/Woodstox wins by a very small margin, the bigger performance
> > gain really comes from using Woodstox instead of the version of Xerces
> > that comes with the JDK.
> >
> > Programming model:
> > Both approaches are very similar. I think I slightly prefer Raymond's
> > StAX-based approach as it allows state to be kept in local variables
> > instead of instance variables shared by multiple event handling methods.
> > Also, I thought that our core StAX loaders were a little fragmented
> > before and that probably caused some of their complexity, but Raymond's
> > new loaders now combines the simplicity of having the parsing logic in a
> > single class (similar to the SAX handlers that I had contributed) and
> > the convenience of the StAX pull parsing model.
> >
> > The other advantage of the StAX based approach is that it covers reading
> > and writing XML documents (although it's easy to write code that
> > produces SAX events to generate a document, as I did in CompositeWriter
> > for example).
> >
> > Dependencies:
> > The SAX based approach works with just a JRE and nothing else. StAX
> > requires Woodstox (or another StAX implementation) or Java 6.
> >
> > To summarize, the StAX loaders are slightly faster, slightly simpler to
> > write, but require Woodstox (about 500Kb). I'd like to remove the SAX
> > handlers that I had contributed in favor of Raymond's new StAX loaders,
> > but since one of the goals of this SCDL4J package is to make SCA really
> > pervasive and allow projects to consume SCA metadata with minimum
> > dependencies, I'd like to make sure that the Woodstox dependency is not
> > going to be a problem for people. Other similar packages like WSDL4J or
> > Woden for example only require the JRE...
> >
> > So, what do people think about this dependency on a StAX parser like
> > Woodstox?
> >
> > If there's no objections I'll switch to use Raymond's StAX loaders
> > around the end of the day on Monday...
> >
> > --
> > Jean-Sebastien
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message