xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edwin Goei <edwi...@sun.com>
Subject Re: Services API?
Date Fri, 12 Oct 2001 00:14:18 GMT
Isaac Shabtay wrote:
> Hey again.
> JAXP has javax.xml.parsers.DocumentBuilderFactory and
> javax.xml.transform.TransformerFactory, which are used to create a factory
> implementation.
> Both have some sequence of searching to the factory implementation name. One
> of the steps is quoted below (from
> javax.xml.parsers.DocumentBuilderFactory's javadoc):
> ========START QUOTE=========
> Use the Services API (as detailed in the JAR specification), if available,
> to determine the classname. The Services API will look for a classname in
> the file META-INF/services/javax.xml.parsers.DocumentBuilderFactory in jars
> available to the runtime.
> Platform default DocumentBuilderFactory instance.
> ========END QUOTE=========
> My question is- what is this "services API"? I've been looking in the JAR
> file specification, and all I could see there is just a short explanation
> about this mechanism. There was no API there. They gave an example there,
> which uses a class named "Service" and a method called "providers", but I
> couldn't find this "Service" class anywhere.

Looks like the javadoc is wrong.  There is no services API being used,
but rather the service provider location mechanism that is documented in
the jar specification is implemented directly in the code.

> The problem is, that currently, Apache's version of
> javax.xml.parsers.DocumentBuilderFactory (as well as
> javax.xml.transform.TransformerFactory) uses "the hard way" in order to get
> this data (constructing an input stream, a reader etc. to read the file,
> then read the line in that file etc.). Anyway, logically, if the "service
> provider" issue is so standardized, it's obvious that some programmatic API
> should be supplied. This way, we can avoid bugs like #2291
> (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2291).
> Any comments? Did I miss anything?

I agree, all code that uses the service provider location mechanism
should share common code.  There is a Service class that implements the
service provider location mechanism that is outlined in the JAR spec,
however, that class is part of JDK 1.4.  Since JAXP also has to run
unbundled from JDK 1.4, it has to have its own implementation.

In any case, I have already fixed the bug you referenced in the
xml-commons module.  The problem is that other projects like xalan and
xerces have not been updated to use the fixed version of the code. 
(Actually, I think Shane said he updated Xalan.)  However, I think the
real fix will be to copy the code from xml-commons as part of the build
so that someone does not have to manually update a copy for each
release.  I implemented such a system for crimson, but it has yet to be
done for the other projects that use the JAXP API.  The same principle
applies to other APIs such as SAX and DOM.  (There may be additional
complexities involved, though.)  Several weeks ago I posted messages on
this topic to xerces-j-dev and general@xml.  I also said I would provide
a patch for the xerces build, but I haven't yet finished that task.

When I fixed the bug, I thought I had closed it, but maybe someone else
opened another bug report.  Not sure whether I should close #2291 or


In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org

View raw message