5 messages in org.apache.xml.commons-devRE: Possible bugs in SchemaFactoryFin...| From | Sent On | Attachments |
|---|---|---|
| Neeraj Bajaj | Jun 6, 2005 2:22 am | |
| Michael Glavassevich | Jun 6, 2005 7:39 am | |
| Michael Glavassevich | Jun 16, 2005 9:30 pm | |
| Morris Kwan | Jun 20, 2005 11:33 am | |
| Nancy Rickson | Jun 20, 2005 12:07 pm |
| Subject: | RE: Possible bugs in SchemaFactoryFinder and XPathFactoryFinder (was: Remaining work for JAXP 1.3 APIs) | |
|---|---|---|
| From: | Nancy Rickson (nric...@catholicexchange.com) | |
| Date: | Jun 20, 2005 12:07:20 pm | |
| List: | org.apache.xml.commons-dev | |
unsubscribe
-----Original Message----- From: Morris Kwan [mailto:mkw...@ca.ibm.com] Sent: Monday, June 20, 2005 1:34 PM To: comm...@xml.apache.org Subject: Fw: Possible bugs in SchemaFactoryFinder and XPathFactoryFinder (was: Remaining work for JAXP 1.3 APIs)
This is a real bug. I have debugged the code in XPathFactoryFinder. The loadFromProperty() method is not able to parse the META-INF/services file correctly. It always returns null even if there is a valid META-INF/services file.
Morris Kwan XSLT Development IBM Toronto Lab Tel: (905)413-3729 Email: mkw...@ca.ibm.com
Michael Glavassevich/Toro nto/IBM@IBMCA To comm...@xml.apache.org 06/17/2005 12:30 cc AM Neer...@Sun.COM Subject Possible bugs in SchemaFactoryFinder and XPathFactoryFinder (was: Remaining work for JAXP 1.3 APIs)
I was recently looking over the source for SchemaFactoryFinder [1] and XPathFactoryFinder [2] and noticed that when processing META-INF/services files it calls a method called loadFromProperty() which reads a META-INF/services file as if it were a properties file. I had thought META-INF/services files are supposed to contain the name of a class, not a name/value pair. In SchemaFactory [3] for the META-INF/services file it says to look at the "JAR file specification for file format and parsing rules". Looking at the JAR file specification [4] it says: "The file should contain a newline-separated list of unique concrete provider-class names", so this seems to agree with what I thought. It sounds like there's a bug here.
Thanks.
[1] http://cvs.apache.org/viewcvs.cgi/xml-commons/java/external/src/javax/xml/va lidation/SchemaFactoryFinder.java?view=markup
[2] http://cvs.apache.org/viewcvs.cgi/xml-commons/java/external/src/javax/xml/xp ath/XPathFactoryFinder.java?view=markup
[3] http://java.sun.com/j2se/1.5.0 /docs/api/javax/xml/validation/SchemaFactory.html#newInstance(java.lang.Stri ng)
[4] http://java.sun.com/j2se/1.5.0 /docs/guide/jar/jar.html#Provider%20Configuration%20File
Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: mrgl...@ca.ibm.com E-mail: mrgl...@apache.org
Michael Glavassevich/Toronto/IBM@IBMCA wrote on 06/06/2005 10:40:17 AM:
Neeraj Bajaj <Neer...@Sun.COM> wrote on 06/06/2005 05:22:42 AM:
Michael Glavassevich wrote:
A diff [4] between the latest copies on the main branch and tck-jaxp-1_2_0 shows some other differences, most notably how the jaxp.properties
file
is
cached. The code on the main branch will read and cache the jaxp.properties file once whereas on the tck-jaxp-1_2_0 branch it will reload it if the jaxp.properties file was modified since it was read (which to me appears to be a more desirable behaviour).
Former is the correct behavior. As per the spec. jaxp.properties should be read only once. http://java.sun.com/j2se/1.5. 0/docs/api/javax/xml/parsers/SAXParserFactory.html#newInstance()
Interesting. The previous version of the spec didn't have this statement
[1] appearently giving implementations the freedom to choose their own caching strategy.
[1] http://java.sun.com/j2se/1.4. 2/docs/api/javax/xml/parsers/SAXParserFactory.html#newInstance()
- Neeraj