From tuscany-dev-return-16433-apmail-ws-tuscany-dev-archive=ws.apache.org@ws.apache.org Tue Apr 03 09:00:30 2007 Return-Path: Delivered-To: apmail-ws-tuscany-dev-archive@locus.apache.org Received: (qmail 80536 invoked from network); 3 Apr 2007 09:00:29 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 3 Apr 2007 09:00:28 -0000 Received: (qmail 70992 invoked by uid 500); 3 Apr 2007 09:00:35 -0000 Delivered-To: apmail-ws-tuscany-dev-archive@ws.apache.org Received: (qmail 70962 invoked by uid 500); 3 Apr 2007 09:00:35 -0000 Mailing-List: contact tuscany-dev-help@ws.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: tuscany-dev@ws.apache.org Delivered-To: mailing list tuscany-dev@ws.apache.org Received: (qmail 70953 invoked by uid 99); 3 Apr 2007 09:00:34 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Apr 2007 02:00:34 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (herse.apache.org: local policy) Received: from [204.127.200.82] (HELO sccrmhc12.comcast.net) (204.127.200.82) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Apr 2007 02:00:26 -0700 Received: from [192.168.1.7] (c-71-202-137-73.hsd1.ca.comcast.net[71.202.137.73]) by comcast.net (sccrmhc12) with ESMTP id <20070403090004012008i7kte>; Tue, 3 Apr 2007 09:00:05 +0000 Message-ID: <4612178C.4010809@apache.org> Date: Tue, 03 Apr 2007 01:59:56 -0700 From: Jean-Sebastien Delfino User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: tuscany-dev@ws.apache.org Subject: Re: Using StAX-based loaders for SCDL? was: SCDL4J References: <01cd01c77361$09a32fe0$0400a8c0@rfengt60p> <460F3BE2.5090606@apache.org> <008101c7754e$03105790$0400a8c0@rfengt60p> <33e260400704030100q1641b266nbfc16a3d6704bc80@mail.gmail.com> In-Reply-To: <33e260400704030100q1641b266nbfc16a3d6704bc80@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on 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 wrote: >> >> +1. >> >> Thanks, >> Raymond >> >> ----- Original Message ----- >> From: "Jean-Sebastien Delfino" >> To: >> 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