• Fixed #229. The interaction between the “always resolve” feature and namespace URI lookup had the unfortunate consequence of returning the (almost always incorrect) document at the namespace URI as the resource. I’ve adjusted the API so that this is no longer the case. It’s now possible to configure “always resolve” on a per-request basis. This changes an interface so it’s not binary backwards compatible with previous 6.x releases.

• Fixed #230. When “always resolve” returned a resource, that URI wasn’t being logged which lead to a confusing log trace.

Changed the API so that an attempt to read a scheme that’s forbidden (by ResolverFeature.ACCESS_EXTERNAL_ENTITY or ResolverFeature.ACCESS_EXTERNAL_DOCUMENT) raises an IllegalArgumentException instead of returning null.

Generally, the XML Resolver tries to avoid throwing exceptions, but in this case failing to do so opens a security vulnerability. Returning null often signals the underlying parser to simply load the resource with the original URI. This circumvents the attempt to limit access.

The 5.3.0 release is a maintance patch on the 5.x branch to provide the security fix for foribidden URIs there as well.

• Reworked the API to use interfaces for ResourceRequest and ResourceResponse. This makes writing a schema handler easier. This is a backwards incompatible change if you were directly accessing those objects. You have to access the ResourceRequestImpl and ResourceResponseImpl instead. On the plus side, the setters are now public on those methods.

• Added code that attempts to detect a Windows path (C:\path) passed as a catalog or property file name and avoid accidentally constructing a URI with the scheme “C”.

This version introduces a new API for registering a scheme resolver. This will allow a resolver to be configured, for example, to handle custom URI schemes as are sometimes found in products.

Fixed a bug where the resolver didn’t set the system identifier of the source. This closes issue 211.

Fixed a bug where the stream opened to read resolver properties might be unclosed. This closes issue 208.

This release restores the NamespaceResolver API. This API is deprecated, but improves backwards compatibility with version 5.x.

This release removes two dependencies: the SLF4J API and the Apache HTTP Client API. This has no user-visible changes in the API, but makes version 6.x of the resolver a drop-in replacement for version 5.x in most cases.

The following changes are included:

Improvements to support for UNC paths

Documents and catalogs that use Windows UNC paths are better supported if the FIX_WINDOWS_SYSTEM_IDENTIFIERS feature is enabled.

Support for Java 21

The build still produces class (and jar) files that will work with any version of Java back to Java 8. However, the build itself now uses Java 21. This closes issue 173.

Refactor the SAX entity resolvers

The SAX EntityResolver and EntityResolver2 interfaces are now implemented on separate objects. This closes issue 183.

Fix namespace-based lookup in the DOM

The LSResourceAdapter API used when resolving documents for the DOM did not correctly handle XML Schema validation. It was failing to lookup based on the namespace. This closes issue 180.

Improved support for concurrency

The catalog lookup code was not sufficiently careful about multi-threaded access. My thanks to JFK-DXML for the patch. This closes issue 182.

Reworked the FIX_WINDOWS_SYSTEM_IDENTIFIERS feature

This feature now applies irrespective of platform. This will enable Windows documents and catalogs to work correctly even on non-Windows systems. This closes issue 184.

A number of smaller issues (testing and build system issues and issues not expected to be user visible) have also been corrected. See the commit log for more details.

Apparently version 6.0.5 was never released.