Project

Profile

Help

Bug #1944

Illegal configuration-file syntax in META-INF/services/javax.xml.xpath.XPathFactory

Added by Wolfgang Hoschek over 2 years ago. Updated about 2 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
JAXP Java API
Sprint/Milestone:
-
Start date:
2013-12-03
Due date:
% Done:

100%

Spent time:
-
Legacy ID:
Applies to branch:
Fix Committed on Branch:
Fixed in Maintenance Release:
Found in version:
9.5
Fixed in version:
9.5.1.5

Description

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


Related issues

Related to Saxon - Bug #2239: META-INF/services/javax.xml.xpath.XPathFactory file is mi... Rejected 2014-11-26
Related to Saxon - Bug #2240: JAXP-XPath page in the documentation need updating Closed 2014-11-27

History

#1 Updated by Michael Kay over 2 years ago

Further information on the history of this problem can be found here:

http://markmail.org/message/obgfqbnrkuhzl6wl

and here:

https://sourceforge.net/p/saxon/discussion/94027/thread/dda095cc

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 2 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 2 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.

Regards,
Johan Mörén

#4 Updated by Michael Kay over 2 years ago

Thanks for the comment. Yes, it's all too common for people to use the JAXP loading mechanism and then write code that relies on the behaviour of a particular implementation.

#5 Updated by Michael Kay over 2 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 about 2 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.

Great. Thanks!

#7 Updated by Johan Mörén about 2 years ago

Great news! Thanks!

#8 Updated by Nikolay Ognyanov about 2 years ago

I am using Saxon-PE 9.5.1.4. For some reason which I have not researched in detail my projects which run fine under Java 6 and Java 7 are hit by this problem under the newly arrived Java 8. Any news and ETA for the fix mentioned above?

#9 Updated by Michael Kay about 2 years ago

We're expecting to produce a maintenance release containing this fix in the next few days.

#10 Updated by O'Neil Delpratt about 2 years ago

  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100
  • Found in version changed from Saxon-HE-9.5.1-3.jar to 9.5
  • Fixed in version set to 9.5.1.5

Bug fix applied in Saxon maintenance release 9.5.1.5

Also available in: Atom PDF