OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SAX-core #2: factories



> 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.

OK, that makes sense to me.


> 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 there are multiple such parsers installed, you need some sort of
mechanism to say which one wins ... I don't seem to recall that
anything says which $JAVA_HOME/jre/lib/ext/*.jar goes first
in the classpath, hence which service definition will win.  In the
same way, different class loaders can also have different sets of
service definitions.

Those are the type problem that $JAVA_HOME/jre/jaxp.properties
is there to address.

 
> It would be great if XMLReaderFactory supported this same sort of mechanism.

Just to keep things straight, I'd count this as a different proposal from
the #2 that I've made (though building on it).  Care to write it up
more fully?

- Dave