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 <[EMAIL PROTECTED]> wrote:

+1.

Thanks,
Raymond

----- Original Message -----
From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]>
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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Reply via email to