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: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
