- Re-designed validation subsystem, which:
- Is fully bi-directional: validation can now be done for both stream readers and writers, using same validators.
- Is pluggable and modular: new implementations can be easily added, 3.0 comes with DTD and RNG validators (latter implemented by MSV, and accessed using a simple wrapper)
- Allows for chaining of validators, allowing validation against multiple types of schemas (as well as different instances of schemas).
- Significant performance improvements to both reader and writers; especially when processing small documents (this on top of already acceptable performance of 2.0 series.)
- Further improvements to XML conformance, now XML 1.0 and 1.1 conformance is over 99% as measure by the industry standard XMLTest conformance suite (tested using SAXTest and SAX wrappers from stax-utils). Specifically conformance of DTD-handling is significantly improved.
- Significantly improved test coverage, both regarding features tested and actual code coverage.
- Improved inter-operability; behavior unified with the Stax reference implementation (including changes to one or both, as dictated by accepted Stax specification interpretations); addition of DOMSource that allows creating of XMLStreamReader from DOM tree; and addition of UTF-32 encoding support.
- Additional operating modes: parsing mode (tree [default], forest, fragment); ability to handle undeclared entities gracefully (in non-entity-expanding mode).
- Unification of writer and reader sides, by adding features writers were missing (optional line number reporting, xml warning handler, disabling of namespace handling), done in the context of Stax2 extended API.
The "Woodstox team" has released version 3.0 of Woodstox XML processor. Woodstox is a high-performance J2EE streaming "pull parser" that implements complete Stax API (JSR-173) including all optional features. Most notable features of this release (compared to the 2.0 series) are:
- Posted by: Tatu Saloranta
- Posted on: August 10 2006 08:54 EDT
- J2EE? by Jason Carreira on August 10 2006 11:47 EDT
- Re: J2EE? by Tatu Saloranta on August 10 2006 14:57 EDT
- Re: Woodstox XML processor v3.0.0 released by Raymond Feng on August 10 2006 19:25 EDT
- Woodstox rocks by Dan Diephouse on August 11 2006 18:30 EDT
- Best XML parser by jim woods on August 12 2006 09:49 EDT
In what way does the word "J2EE" belong in
high-performance J2EE streaming "pull parser"
As an obligatory buzzword? J2EE is a broad and vague (or ambiguously used) term, but since Stax API is being included in (or depended by) many J2EE APIs, such as JAX-B and JAX-WS, and used by many implementations of enterprise server-side components (such as XFire, Axis 2, ServiceMix etc), it seems reasonable to add the acronym in there. So it more relates to Stax than Woodstox itself. But I guess being discussed at TSS kind of implies all this. And yes, one could easily understand the rest of sentence without j2ee being in there. ;-)
I would say it's definitely NOT reasonable to add J2EE in there since it adds no extra value (except for your marketing purpose). StAX is not included in the J2EE API. Wouldn't you like to see people using your product outside of the J2EE scope?
I would say it's definitely NOT reasonable to add J2EE in there since it adds no extra value (except for your marketing purpose). StAX is not included in the J2EE API. Wouldn't you like to see people using your product outside of the J2EE scope?Does it really matter?
Yes, if you want to avoid contributing to the fact that "J2EE is a broad and vague (or ambiguously used) term" as per stated above.
I would say it's definitely NOT reasonable to add J2EE in there since it adds no extra value (except for your marketing purpose). StAX is not included in the J2EE API.Considering Woodstox is a free open source project, I don't think there's much need for marketing per se; and specifically I doubt inclusion (or lack thereof) of j2ee has much effect either way. But regarding your statement about Stax not being part of J2EE API: I find it weird that you make strong comments about something you do not seem to know very much about. Please have a look at J2EE 1.5 package (http://java.sun.com/javaee/5/docs/api/), under javax.xml.stream, then compare with Stax API (JSR-173), and see if you notice any similarities. Yes, Stax API is indeed part of J2EE 1.5 API -- it has to be, since JAX-B 2.0 (and probably JAX-WS 2.0) depend on it.
My bad, I admit I missed the inclusion in 1.5. However, a mail client using the javax.mail.* package - would you call that a "J2EE mail client" even if it's a SWING app? That's my point. Of course Open Source needs marketing, what do you think this post is? Good luck with the product, I will check it out regardless of the usage of J2EE ;-)
When will the 3.0.0 version be uploaded to the maven2 repository?
Woodstox is really the best XML parser out there. Its the fastest parser, conformant with the xml spec, and pretty much bug free. If you're using another StAX parser out there (like the StAX reference implementation) you should really switch. I remember doing performance tests of how the performance differed between Woodstox and the StAX RI within a typical XFire web service. Using the Woodstox gave an instant 30% performance boost. And now its even faster!
I think Woodstox is the best Java XML parser,it's very fast. Developers dig
There's no 1.5 J2EE, it's called Java 5 EE :-) Whether it's J2EE or Java EE, though, including this in the name is misleading and unnecessary (since it's perfectly usable outside of J(2)EE). Or isn't it?
There's no 1.5 J2EE, it's called Java 5 EE :-)Terminology used elsewhere (to describe Woodstox) hasn't really included j2ee as a term. And I won't be adding it for further notices; I agree it doesn't really add information relevant to evaluating its usefulness (compared to highlighting actual features and implementation details).
Whether it's J2EE or Java EE, though, including this in the name is misleading and unnecessary (since it's perfectly usable outside of J(2)EE). Or isn't it?
And yes, it's perfectly usable outside, as long as one includes the Stax API jar (which doesn't depend on other EE APIs, just ones that are also included within SE).
Anyhow, thanks for all the comments (to you and all posters above) -- there could be worse flaws in software than erroneous reference to j2ee in its marketing material. ;-)