Bump xmlresolver from 1.1.0 to 2.1.0

[dependabot[bot]]

Bumps xmlresolver from 1.1.0 to 2.1.0.

Release notes

Sourced from xmlresolver's releases.

XML Resolver 2.1.0

Version 2.1.0 fixes a bug in the way the cache is managed in the case where multiple threads are competing for the cache. Basically, I misunderstood way NIO locks work. I expected the lock attempt to block until the lock is available, but it doesn't. I throws an exception. In this version, the lock attempt catches that exception and retries until the lock is obtained.

Version 2.0.x introduces some API changes. The most common user-level APIs (new Catalog(), new Resolver(), etc. are unchanged), but if you’re extending or integrating with the resolver directly, you may have to change a few things. I’ve added a ResolverFeature type to track features in a more typesafe way.

The Configuration object has been renamed XMLResolverConfiguration and now implements the ResolverConfiguration interface. Several methods on the configuration object have been removed. Their values can be obtained by requesting the corresponding feature.

Behavior changes

The resolver class can be configured with either system properties or a properties file. In version 1.x, if a property file is used, the values specified in that file always take precedence.

This means that you can’t, for example, selectively override the catalog file list for a single application by specifying a system property.

On reflection, that seems backwards. In 2.x, if a property is specified in both places, the system property wins.

To keep the existing behavior, set the boolean property prefer-property-file to true in the property file. That will preserve the former behavior. (The system property equivalent is xml.catalog.preferPropertyFile.)

Support for data: URIs

It is now possible to use data: URIs in the catalog. Data URIs are defined by RFC 2397. For example, this catalog entry:

  <uri name="http://example.com/example.xml"
       uri="data:application/xml;base64,PGRvYz5JIHdhcyBhIGRhdGEgVVJJPC9kb2M+Cg=="/>

maps the URI http://example.com/example.xml to a short XML document defined by that data URI (<doc>I was a data URI</doc>).

Support for classpath: URIs

It is now possible to use classpath: URIs in the catalog. It is also possible to use classpath: URIs in the catalog list. The classpath: URI scheme seems to be defined somewhat informally by the Spring framework.

In brief, a classpath: URI is resolved by attempting to find a document with the specified path in the classpath, including within JAR files on the classpath.

This catalog entry:

   <uri name="http://example.com/example.xml"
        uri="classpath:path/example-doc.xml"/>

maps the URI http://example.com/example.xml to a document with the path path/example-doc.xml on the classpath. (Searches always begin at the root of the classpath segments, so path/example-doc.xml and /path/example-doc.xml are equivalent.)

(For what it’s worth, the resolver also supports classpath*: but since that’s defined as concatenating the resources identified, it’s of comparatively little use in the XML case.)

Suppose, for example, that your classpath includes /home/ndw/java/libs/example.jar:

 $ jar vtf /home/ndw/java/libs/example.jar
      0 Wed May 05 14:51:50 BST 2021 META-INF/
     25 Wed May 05 14:51:50 BST 2021 META-INF/MANIFEST.MF
</tr></table> 

... (truncated)

Commits

• 68b9d6f XML Resolver 2.1.0
• 6037b1b Handle lock contention on the cache
• 4ab392e XML Resolver 2.0.0
• 1a87645 Return the file:jar:... URIs for resources resolved with classpath:
• c90eeab Added static version() method
• e41e40c Code cleanup
• e13b9b3 Fix grammatical error :-(
• cdfa713 Updated README with details about how classpath: works
• 49bcda2 Merge pull request #38 from ndw/use-features
• d8008a4 Publication tweaks
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually

[dependabot[bot]]

Superseded by #78.