Bug #2306: InvalidCastException: Unable to cast object of type org.apache.xml.resolver.tools.CatalogResolver - Saxon - Saxonica Developer Community

Actions

Send by e-mail Copy link

Bug #2306

closed

InvalidCastException: Unable to cast object of type org.apache.xml.resolver.tools.CatalogResolver

Added by O'Neil Delpratt almost 10 years ago. Updated about 9 years ago.

Status:

Closed

Priority:

Normal

Assignee:

O'Neil Delpratt

Category:

.NET API

Sprint/Milestone:

9.6.0.6

Start date:

2015-02-02

Due date:

% Done:

100%

Estimated time:

Legacy ID:

Applies to branch:

9.6

Fix Committed on Branch:

9.6

Fixed in Maintenance Release:

9.6.0.6

Platforms:

Description

Bug issue reported from https://saxonica.plan.io/boards/3/topics/5992:

Unhandled Exception: System.InvalidCastException: Unable to cast object of type 'org.apache.xml.resolver.tools.CatalogResolver' to type 'net.sf.saxon.dotnet.DotNetURIResolver'.
   at Saxon.Api.Processor.get_XmlResolver()
   at Saxon.Api.Processor.NewDocumentBuilder()
   at ConsoleApplication1.Program.Main(String[] args)

The assumption here is that a user supplies an .NET XMLResolver on the Processor property. If not supplied the default is to use the Java URIResolver. This causes the class exception to be thrown.

There are two possible ways to solve this bug. The first option is to return null if the URIResolver is not an instance of the .NET URIResolver. The second option is to return the default XMLResolver created in the .NET Processor class.

Related issues

Actions

Copy link

Updated by O'Neil Delpratt almost 10 years ago

Status changed from New to Resolved
% Done changed from 0 to 100

We have decided upon the second option, which is to return the default .NET XmlResolver.

Bug fixed and committed to subversion

Actions

Copy link

Updated by O'Neil Delpratt over 9 years ago

Status changed from Resolved to In Progress

I am reopening this bug because the fix is causing the Java products to fail with the following exception (note: pre-maintenance release):

Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/xml/resolver/tools/CatalogResolver
	at net.sf.saxon.trans.DynamicLoader.registerKnownClasses(DynamicLoader.java:42)
	at net.sf.saxon.trans.DynamicLoader.<init>(DynamicLoader.java:29)
	at net.sf.saxon.Configuration.<init>(Configuration.java:142)
	at com.saxonica.config.ProfessionalConfiguration.<init>(ProfessionalConfiguration.java:134)
	at com.saxonica.config.EnterpriseConfiguration.<init>(EnterpriseConfiguration.java:103)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
	at java.lang.Class.newInstance(Class.java:374)

Actions

Copy link

Updated by O'Neil Delpratt over 9 years ago

Status changed from In Progress to Resolved

The fix applied was to add processor directives to the code in the DynamicLoader class to make it DOTNET specific.

Actions

Copy link

Updated by O'Neil Delpratt over 9 years ago

Status changed from Resolved to Closed
Fixed in version set to 9.6.0.5

Bug fix applied in the Saxon 9.6.0.5 maintenance release.

Actions

Copy link

Updated by O'Neil Delpratt over 9 years ago

Status changed from Closed to In Progress

Reopening this bug it still occurs in 9.6.0.5 as reported in https://saxonica.plan.io/boards/3/topics/5992?r=6098#message-6098

Actions

Copy link

Updated by O'Neil Delpratt over 9 years ago

Status changed from In Progress to Resolved

A call on XmlResolver property is also possible in the XsltCompiler classt therefore the same fix as mentioned in comment #0 and #1 is required.

Bug has now been fixed and committed to subversion and will be available in the next maintenance release (i.e. 9.6.0.6). An nunit test case has been created to check for regression in future releases.

Actions

Copy link

Updated by O'Neil Delpratt over 9 years ago

Fixed in version deleted (~~9.6.0.5~~)

Update on this bug see comment https://saxonica.plan.io/boards/3/topics/5992?r=6111#message-6111

In summary the Compile(Uri) always seems to invokes the Microsoft .NET XMLReader. We have refactored this method to build a stream from the Uri then to do similar to the compile(stream) method.

Actions

Copy link