Bug #5306


Saxon 11.1 breaks my code (SAXParserFactory.newInstance() problem is back)

Added by Gerben Abbink over 2 years ago. Updated over 2 years ago.

Start date:
Due date:
% Done:


Estimated time:
Legacy ID:
Applies to branch:
11, trunk
Fix Committed on Branch:
Fixed in Maintenance Release:


In Configuration.init() a CatalogResourceResolver is created:

commonResolver = new CatalogResourceResolver();

This leads to


in org.xmlresolver.cache.ResourceCache, which looks at the global system property


I have to use the global property for other parts in my source code (set to org.apache.xerces.jaxp.SAXParserFactoryImpl), and up to now Saxon was neglecting the property.

I thought JAXP and global properties are considered "evil"?

Any ideas how I can solve the problem?

Here is the stack:

InvocationTargetException Provider org.apache.xerces.jaxp.SAXParserFactoryImpl not found java.xml/javax.xml.parsers.FactoryFinder.newInstance( java.xml/javax.xml.parsers.FactoryFinder.newInstance( java.xml/javax.xml.parsers.FactoryFinder.find( java.xml/javax.xml.parsers.SAXParserFactory.newInstance( org.xmlresolver.cache.ResourceCache.( org.xmlresolver.XMLResolverConfiguration.getFeature( org.xmlresolver.CatalogResolver.( org.xmlresolver.Resolver.( net.sf.saxon.lib.CatalogResourceResolver.( net.sf.saxon.Configuration.init( net.sf.saxon.Configuration.( java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance( java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance( java.base/java.lang.reflect.Constructor.newInstanceWithCaller( java.base/java.lang.reflect.Constructor.newInstance(

Related issues

Related to Saxon - Bug #5096: .NET: FactoryConfigurationError: Provider org.apache.xerces.jaxp.SAXParserFactoryImpl not foundClosedMichael Kay2021-09-17

Actions #1

Updated by Michael Kay over 2 years ago

  • Category set to Internals
  • Assignee set to Norm Tovey-Walsh
  • Applies to branch 11, trunk added

Sounds as if it would be a good idea if the CatalogResolver supplied an alternative way to instantiate an XML parser, as an alternative to the JAXP mechanism.

You can always set your own Configuration-level ResourceResolver that does nothing (always returns null) but I don't know if that would have unwanted side-effects.

Actions #2

Updated by Michael Kay over 2 years ago

Note there is a relationship to bug #5096, which is a failure to do dynamic loading of the SAX parser from the old catalog resolver in Saxon/.NET 10.6; which could also be solved by allowing the user to supply an XMLReader directly, rather than relying on the JAXP mechanism to get one.

Actions #3

Updated by Michael Kay over 2 years ago

  • Related to Bug #5096: .NET: FactoryConfigurationError: Provider org.apache.xerces.jaxp.SAXParserFactoryImpl not found added
Actions #9

Updated by Norm Tovey-Walsh over 2 years ago

  • Status changed from New to Resolved
Actions #10

Updated by Norm Tovey-Walsh over 2 years ago

  • Status changed from Resolved to Closed
  • Fixed in Maintenance Release 11.2 added

Please register to edit this issue

Also available in: Atom PDF