ppkarwasz opened a new pull request, #28: URL: https://github.com/apache/commons-xml/pull/28
## Relationship to COMMONSXML-3 This PR is adjacent to [COMMONSXML-3](https://issues.apache.org/jira/browse/COMMONSXML-3) (Reduce shading footprint), but deliberately stops short of it: it does **not** add alternative public entry points. It is too soon to commit to a per-hardener API, so `XmlFactories` remains the only public class and its API is unchanged. What it does instead is consolidate methods by moving each shared helper to its only caller, so that the internals no longer form one tangle in which every class transitively reaches every other. Each JAXP type (DOM, SAX, StAX, TrAX, XPath, schema) now has a self-contained hardener whose transitive class closure contains only what that type actually uses. If COMMONSXML-3 is taken up later, exposing an entry point becomes a visibility change instead of a refactoring. ## Changes One commit per step, each behavior-preserving: 1. **Centralize hardening messages on `HardeningException`.** Two static helpers, `settingFailed(...)` and `forbidden(...)`, replace the message construction that previously coupled the setters and the resolver floors to their container classes. Messages are byte-identical. 2. **Inline the typed JAXP setters into each hardener.** The `setFeature`/`setOptionalFeature`/`trySetProperty` helpers move out of the shared `JaxpSetters` class into the hardener that uses them, as private methods; `JaxpSetters` is deleted. Shading one hardener no longer drags in the setter overloads of the others. 3. **Split the resolver floors into top-level classes.** The five nested `Resolvers.Fallback*` floors become top-level, package-private classes (`FallbackDenyEntityResolver2`, `FallbackDenyXMLResolver`, `FallbackIgnoreXMLResolver`, `FallbackDenyURIResolver`, `FallbackDenyLSResourceResolver`) and the `Resolvers` container is deleted. Nested classes are kept together by `minimizeJar`; top-level classes are pulled in per floor. 4. **Break the `XmlFactories` cycle for TrAX, XPath and schema.** The wrappers re-hardened their sub-parsers by calling back into `XmlFactories.harden(Source/XMLReader)`, and since `XmlFactories` news up every hardener, that one call dragged the whole library into their closures. The bodies move to package-private `SAXParserHardener.hardenSource`/`hardenReader`; the public `XmlFactories.harden` methods stay as thin delegates. 5. **Add `SchemaHardener` as the schema entry point.** Package-private like the other hardeners; it gives schema validation the same shape as the other types (`XmlFactories` delegates to a dedicated hardener) and would back a public entry point later. ## Effect on the shade closures Before this PR the TrAX, XPath and schema entry points transitively reached `XmlFactories` and therefore pulled the whole library (32 classes each), while the DOM, SAX and StAX hardeners pulled the shared setter class and all five resolver floors whether they used them or not. After: | Entry point | Classes in closure | |---------------------------|--------------------| | `DocumentBuilderHardener` | 5 | | `StaxHardener` | 6 | | `SAXParserHardener` | 8 | | `XPathHardener` | 13 | | `SchemaHardener` | 14 | | `TransformerHardener` | 17 | | `XmlFactories` (public) | 33 (whole library) | TrAX, XPath and schema build on the shared SAX closure (8 classes), since they re-harden their sub-parsers through it. The new `ShadingFootprintTest` pins each closure with jdependency (the library `maven-shade-plugin`'s `minimizeJar` uses), so a hardener silently regaining a dependency on a sibling floor or another hardener fails the build. The test is JVM-only and excluded from the Android test compile. ## Testing Full surefire matrix (stock JDK, Xerces, Xalan, Xalan+Xerces, Saxon, Saxon+Xerces, Woodstox): all green. No public API change, no behavior change; exception messages are byte-identical. 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
