ppkarwasz opened a new pull request, #72: URL: https://github.com/apache/commons-secure-xml/pull/72
A JAXP `SAXParser` hands out one `XMLReader` for its lifetime — both the stock JDK and Xerces hold it in a `final` field and return that instance from every `getXMLReader()` call — and `reset()` reverts it to its just-created state, restoring the initial (resolver-less) entity resolver captured before the floor existed. `SecureSAXParser.reset()` responded by dropping its cached views, so the floor was re-installed on the *next* `getXMLReader()` call. A caller that kept the reader it had already obtained — which is the case `reset()` exists for, instance reuse — went on parsing through that same underlying reader with no floor on it. The existing `ResetSecureTest` case materialised a reader before the reset but then re-fetched it afterwards, so it exercised the re-secured view rather than the retained one. The fix re-secures the reader in place, through the view already vended, matching the eager pattern `SecureDocumentBuilder.reset()`, `SecureTransformer.reset()` and `SecureValidator.reset()` already use. Keeping a single wrapper also avoids orphaning its floor: a resolver the caller sets on that view stays routed through the floor that is actually installed. Tests: - `ResetSecureTest.saxParserResetKeepsFloorOnReaderVendedBeforeReset` — holds the reader across the reset and parses through it. It fails on both the `test-stockjdk` and `test-xerces` executions without the main-code change, and passes with it. - `SecureSAXParserTest` — the reset case now asserts the security property (the views survive the reset and the floor is back on the underlying reader) instead of the previous mechanism (that the views are recreated), and is renamed accordingly. Verified with the full surefire matrix and the GraalVM `-Pnative-xalan` native suite. No `changes.xml` entry: the behaviour lands in the same release cycle that introduced it. 🤖 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]
