RE: SAX-core #2: factories

[Michael Brennan <Michael_Brennan@allegis.com>]

I was thinking of META-INF/services support _in addition_ to a compiled-in
default. The compiled-in default makes sense as a fallback. And I was
thinking of just adding it for the XMLReaderFactory class (similar to JAXP's
use of this mechanism for the SAXParserFactory class), but not retrofitting
SAX1 ParserFactory.

I'm personally not fond of the installation-wide defaulting by putting
properties files in the JDK installation directory tree, but that's just my
opinion. I prefer configuration mechanisms that support self-contained
distributions that are easy to distribute and install on multiple machines.
The META-INF/services/ seems well suited to that. With JAXP, it's sufficient
to put the appropriate JARs from a particular parser distribution on the
classpath, and you get that implementation as the default. If Crimson is on
the classpath, then calling SAXParserFactory.newInstance gives you the
Crimson implementation; if Xerces is on the classpath, then you get the
Xerces implementation. No other configuration is necessary. Very convenient.


It would be great if XMLReaderFactory supported this same sort of mechanism.
I've experienced some oddities with Sun's reference implementation where
creating a SAXParser from a SAXParserFactory and then calling "getXMLReader"
and trying to work directly with that XMLReader caused an exception with the
message "org.xml.sax.driver system property not set". I haven't consistently
recreated that, though, so I haven't tracked down the specific scenario
where that's arising (I have a bug in some code of ours on my plate that is
related to this, but haven't gotten to it, yet).

> -----Original Message-----
> From: David Brownell [mailto:david-b@pacbell.net]
> Sent: Tuesday, August 07, 2001 5:23 PM
> To: Michael Brennan; sax-devel@lists.sourceforge.net
> Cc: xml-dev@lists.xml.org
> Subject: Re: SAX-core #2: factories
> 
> 
> In fact I'd probably like to go farther than just adding a
> compiled-in default. JAXP has enough bootstrap flexibility,
> except it returns something that's not a SAX2 parser.  It
> checks four places to find the default (non-SAX) parser
> class, I think it's this order:
> 
>     * system property (SAX does too) if possible
>         --> per-JVM-instance defaulting
>     * $(JAVA_HOME)/jre/lib/jaxp.properties
>         --> installation-wide defaulting
>     * META-INF/services/... resource (usually in jarfile)
>         --> can vary based on thread's class loader config
>               (threads' loaders may see different resources)
>     * compiled-in default (this proposal adds to SAX)
>         --> can also vary based on thread's class loader config
>               (with different javax.xml.parsers implementations)
> 
> Only the compiled-in default can work in all configurations;
> access permissions can get in the way of looking up the
> default using all the other mechanisms (fragile).
> 
> Michael, are you suggesting adding the META-INF/services
> support _in addition_ to a compiled-in default?  Or instead
> of that?  I wonder if an installation-wide default would be
> appropriate (check jaxp.properties?) and whether SAX1
> ParserFactory deserves such updates (I'd assume not).