You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jean-Sebastien Delfino <js...@apache.org> on 2007/04/01 06:58:10 UTC
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
Re: Using StAX-based loaders for SCDL? was: SCDL4J
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Venkata Krishnan wrote:
> 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 <en...@gmail.com> wrote:
>>
>> +1.
>>
>> Thanks,
>> Raymond
>>
>> ----- Original Message -----
>> From: "Jean-Sebastien Delfino" <js...@apache.org>
>> To: <tu...@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
>> >
I changed the modules under java/sca/scdl4j to use the StAX loaders
(revision r525085) and removed the SAX based loaders and writers. I
should be able to contribute new StAX based model writers in a day or two.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Using StAX-based loaders for SCDL? was: SCDL4J
Posted by Venkata Krishnan <fo...@gmail.com>.
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 <en...@gmail.com> wrote:
>
> +1.
>
> Thanks,
> Raymond
>
> ----- Original Message -----
> From: "Jean-Sebastien Delfino" <js...@apache.org>
> To: <tu...@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
>
>
Re: Using StAX-based loaders for SCDL? was: SCDL4J
Posted by Raymond Feng <en...@gmail.com>.
+1.
Thanks,
Raymond
----- Original Message -----
From: "Jean-Sebastien Delfino" <js...@apache.org>
To: <tu...@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