James Duncan Davidson wrote:
>
> > on page 21 the method SAXParser.getParser() is declared to throw a
> > SAXException, but later on, on page 23, that exception is not reflected
> > into the documentation. I believe the mistake resides on page 21,
> > because nothing should happen in the getParser() method but returning
> > the already instantiated and configured Parser() instance to the caller.
>
> Unfortunatly, the mistake is on page 23. In the javax.xml.parsers
> documentation, we define the getParser method to throw the exception. The
> ommission on the method description is erroneous.
Unfortunately :) Probably in version 1.1 it'll be removed. Anyway, as
long as the two descriptions are coherent, it's good for me.
> > Also, I don't understand why the SAXParserFactory.newSAXParser() should
> > throw a SAXException, while DocumentBuilderFactory.newDocumentBuilder()
> > doesnt. Those methods already throw a ParserConfigurationException, so,
> > in my very humble opinion, the SAXException is redundant.
>
> The SAXException is intended to be thrown by the underlying SAX
> implementation while the ParserConfigException is thrown by the factory in a
> condition where the set configuration isn't valid. It is arguable redundant
> and we might want to address this in a future rev of the API.
I agree with you on that, in fact, expecially when considering SAX2
properties and features, SAXExceptions come always into play when
creating the real parser instance. But, so, if we have it in SAXParser,
we should also have it in DocumentBuilder (for simmetry). Again, JAXP
1.1?
> > The last thing, I developed an implementation for the Apache XERCES
> > parser, both of the javax.xml.parser classes, and for their relative
> > implementation under the org.apache.xerces.jaxp package. If you could
> > give them a look and send me some feedback that would be greatly
> > appreciated (I implemented the javax.xml.parser classes also since
> > there's not an implementation currently available conforming to the
> > given spec, as far as I can see).
>
> Nope, there's not a .jar file that implements the spec avaialble yet. It'll
> be out with the JAXP reference implmenetation "Real Soon Now". There isn't
> an issue for you having your own implmentation, though when we do get our
> jaxp.jar out there, you'll probably want to pick it up so that you don't
> have to maintain those interfaces. :)
The only "issue" I see right now in having two implementations is that
Sun's RI will probably default to Project-X, in case no System property
is found, while mine defaults to Xerces. Given the fact that there is no
"easy" way for specifying system properties in the current JDKs up to
1.2 (apart from command line options), depending on the JAXP
implementation you choose, you have a default parser.
What I want to be able to have is to be able to compile a XML enabled
application regardeless of what parser you have in your CLASSPATH, and
then running it, again, regardeless of what JAXP implementation (and so
default parser) you have.
Let's say that ANT.next uses JAXP. You have Project-X in your CLASSPATH,
and you develop and compile ANT using it. When it comes to me, and I use
XERCES, if we use the same JAXP classes, I will be forced to start ANT
either with one more command line option, otherwise I will be required
to have Project-X, because the JAXP classes default to it (and I would
get not even an exception, but an Error!).
So, since it's 4 classes, and they're really trivial to write, I'd see
every parser distributed with a "localized" copy of those, with the
appropriate default.
If the R.I. allows to "customize" the default (a properties file?), I'll
be more than happy to drop it, but, if not, until JDK-1.4 (where I
believe you'll be able to write system properties in a jdk-wide
configuration file), I'd say, let's keep different implementations.
Thanks.
Pier
--
--------------------------------------------------------------------
- P I E R -
stable structure erected over water to allow the docking of seacraft
<mailto:[EMAIL PROTECTED]> <http://www.betaversion.org/~pier/>
--------------------------------------------------------------------
- ApacheCON Y2K: Come to the official Apache developers conference -
-------------------- <http://www.apachecon.com> --------------------
