oscerd commented on PR #26108: URL: https://github.com/apache/camel/pull/26108#issuecomment-5570215188
@davsclaus thanks for catching the CI failure. I dug into it, and the test was indeed broken — but for a different reason than the one in your analysis. Here is what I measured. **The restriction does fire.** I ran the same test against the same commit, toggling only `FopProducer` between `main` and this PR: | | JDK 21 | JDK 25 | |---|---|---| | **without** this change | `java.io.FileNotFoundException: /non-existent-external.dtd` | same | | **with** this change | `Access to URI file:///... has been prohibited` | same | Without the change the JVM raises a `FileNotFoundException`, which means the parser **actually opened** the external DTD. With the change that I/O never happens — the access is refused first. So `ACCESS_EXTERNAL_DTD` on the `TransformerFactory` is applied at the layer that matters here: the identity transformer parses the `StreamSource` with its own reader and pushes SAX events into `fop.getDefaultHandler()`, so FOP never sees the `<!DOCTYPE>` itself. I could not find an input path on this producer where FOP resolves it instead, so I have not touched `FopFactory` — happy to revisit if you know of one. **What actually broke CI** was the assertion, not the production change. The test matched the literal `"accessExternalDTD"` text of the JDK error message. Newer JDKs reworded that message to `"Access to URI ... has been prohibited"`, which does not contain the property name. My local JDK 21 still emits the old wording — that is why it was green before pushing — while CI's JDK 17 and 25 emit the new one. **Fix pushed** in 55ac210: the test no longer looks at message text. The `<!DOCTYPE>` now points at a real, readable DTD written to a `@TempDir`, so resolving it would *succeed*; the transformation failing is itself the proof that it was never fetched. A second test renders the identical XSL-FO document without a `<!DOCTYPE>`, so the first cannot pass for the wrong reason. Verified to pass on JDK 21 and JDK 25 with the producer change, and to fail on both without it — so it is a real regression guard on either message wording. _Claude Code on behalf of oscerd_ -- 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]
