Illegal configuration-file syntax in META-INF/services/javax.xml.xpath.XPathFactory
Using Saxon-HE-9.5.1-*.jar, we are running into the same issue that was already reported in http://stackoverflow.com/questions/7914915/syntax-error-in-javax-xml-xpath-xpathfactory-provider-configuration-file-of-saxo , this time on Java8 and IBM J9.
For various reasons our code using JAXP XPathFactory.newInstance() can't be changed to use other patterns requesting a more specific implementation.
It occurs to me that, if Saxon doesn't support Java5 anymore, maybe the invalid newlines in META-INF/services/javax.xml.xpath.XPathFactory can now be fixed without causing negative compat side effects. Java6&7 seemed to tolerate the invalid newlines, but Java8 and IBM J9 are more strict and throw
ServiceConfigurationError: javax.xml.xpath.XPathFactory: jar:file:/tmp/lib/Saxon-HE-9.5.1-3.jar!/META-INF/services/javax.xml.xpath.XPathFactory:2: Illegal configuration-file syntax
#1 Updated by Michael Kay over 6 years ago
Further information on the history of this problem can be found here:
As stated on those threads, the problem originally arose because we wrote the services file to do what JDK 5 implemented, not what the JDK documentation said. It's probably time to move on now and do what the documentation says, leaving a problem only for those who are still using the old JDK.
Alternatively, I'm sorely tempted to abandon using the JAXP search mechanism entirely, at least for XPath. The utility of a mechanism that returns either an XPath 1.0 processor or an XPath 2.0 processor depending on what it happens to find on the classpath is highly questionable, and the JAXP XPath API is in any case so badly designed that we really don't want to encourage its use.
#2 Updated by Wolfgang Hoschek over 6 years ago
Thanks for the quick reply! Indeed, abandoning the dubious JAXP ServiceLoader search mechanism (i.e. removing META-INF/services/javax.xml.xpath.XPathFactory) would be an even better fix for our problem here. On the other hand if you'd consider this too big a change for a Saxon-HE-9.5.1-x maintenance release, then, in the interest of seeing a fix sooner rather than later, I'd vote for fixing the newlines in Saxon-HE-9.5.1-x.
#3 Updated by Johan Mörén over 6 years ago
We ran into problems with the ServiceLoader mechanism when we, in the same class loader, want to use saxon 9.5.* internally for XPATH 2. But also rely on a third party library that use XPath via JAXP and assumes via casts that the object model returned is for example a Node and not a TinyDocumentImpl. Resulting in a ClassCastException.
We discovered this problem when upgrading from Saxon 8.7 to 9.5.1-3. Both versions uses the ServiceLoader mechanism but we only ran into problems when using the later version. In our own code we are not relying on this mechanism. We instead specify object model, implementation class and class loader when calling XPathFactory.newInstance(). The third party code just uses the XPathFactory.newInstance() without arguments.
I haven't tried to modify the jar and remove the meta-inf/services folder. But i guess this might fix our problem. It however seems like a hack and will be hard to document and maintain in the long run.
Perhaps Saxon could be released in alternative versions for each release. One with the ServiceLoader mechanism and one without? I'm also very sceptic of the mechanism and would have no problem with it disappearing in a future release.
#5 Updated by Michael Kay over 6 years ago
- Status changed from New to Resolved
- Assignee set to Michael Kay
I have updated the build scripts so that:
In the next maintenance release of 9.5, we will use the correct JDK 1.6 format for these files, which means they will not work under JDK 1.5
In Saxon 9.6, we will drop these files entirely, so the Saxon XPath processor will no longer be picked up by a JAXP factory search.
#6 Updated by Wolfgang Hoschek over 6 years ago
Michael Kay wrote:
I have updated the build scripts so that:
- In the next maintenance release of 9.5, we will use the correct JDK 1.6 format for these files, which means they will not work under JDK 1.5
- In Saxon 9.6, we will drop these files entirely, so the Saxon XPath processor will no longer be picked up by a JAXP factory search.
Please register to edit this issue