Does the XML Catalog reliably redirect schema requests to a known‑good version after a failed upgrade, and what are its caching limits?

Redirection Reliability and Fallback Logic

An XML Catalog does not inherently provide a "fallback" mechanism that triggers only after a failed upgrade. Instead, it acts as a proactive lookup table. If a mapping exists in the catalog for a specific System ID or Public ID, the parser redirects the request to the mapped local URI before attempting to fetch the remote resource. Consequently, the parser will not emit a schema-load error for a newer version if the catalog has already redirected that request to a known-good local version.

Likely Implementation Behavior

Because the redirection happens at the resolution phase, the following behaviors are typical in standard OASIS XML Catalog implementations:

• Error Events: No error event is emitted for the "failed" remote load because the remote load is never attempted. The parser simply sees the local file as the authoritative source.
• Caching: The catalog file itself is usually loaded into memory once per CatalogResolver instance. However, the resulting schema (the XSD) is often cached by the parser's internal schema factory or a JAXB context. If the catalog is updated on disk, the parser may continue using the previously cached schema until the resolver or the application context is restarted.
• Concurrency: Most CatalogResolver implementations are read-only after initialization. If an application attempts to update the catalog file concurrently, the behavior is undefined and depends on the file system; however, since the catalog is typically cached in memory, threads will likely continue seeing the version loaded at startup, avoiding race conditions but introducing staleness.

Verification Steps

To verify that your redirection is working and to test the boundaries of your parser's caching, use the following scoped approach:

1. Force Redirection: Create a catalog.xml with a rewrite rule mapping the remote schema URI to a local path.
2. Isolate Network: Disable network access for the process (e.g., using a firewall or -Djava.net.useSystemProxies=false in some JVM environments) to ensure the parser cannot reach the remote server.
3. Validate: Run the validation task. If it succeeds, the catalog is redirecting correctly.
4. Test Cache: Modify the local schema file and re-run the task. If the validation results do not change, the schema is being cached by the parser/context, regardless of the catalog's state.

Missing Diagnostic Detail: To provide a more specific answer regarding race conditions and caching, please specify the XML parser and version (e.g., Xerces-J 2.12, Saxon) and whether the CatalogResolver is shared across threads.