You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@xml.apache.org by Isaac Shabtay <is...@netvision.net.il> on 2001/10/11 23:20:51 UTC
Services API?
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.
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?
- Isaac
---------------------------------------------------------------------
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
Re: Services API?
Posted by Isaac Shabtay <is...@netvision.net.il>.
> 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.
I've searched the JDK 1.4 javadocs, couldn't find any "Service" class (I
looked in the "All Classes" summary of the javadocs).
Could you please point me to the exact location?
- Isaac
Re: Services API?
Posted by Edwin Goei <ed...@sun.com>.
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
not.
-Edwin
---------------------------------------------------------------------
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
Re: Services API?
Posted by Edwin Goei <ed...@sun.com>.
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
not.
-Edwin