You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@camel.apache.org by "Claus Ibsen (Jira)" <ji...@apache.org> on 2026/07/16 15:13:00 UTC
[jira] [Resolved] (CAMEL-24111) camel-xslt: dead InputStream close logic in XsltBuilder.process() since the SourceHandlerFactory refactoring
[ https://issues.apache.org/jira/browse/CAMEL-24111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Claus Ibsen resolved CAMEL-24111.
---------------------------------
Resolution: Fixed
> camel-xslt: dead InputStream close logic in XsltBuilder.process() since the SourceHandlerFactory refactoring
> ------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-24111
> URL: https://issues.apache.org/jira/browse/CAMEL-24111
> Project: Camel
> Issue Type: Bug
> Components: camel-xslt
> Affects Versions: 4.21.0
> Reporter: Federico Mariani
> Assignee: Claus Ibsen
> Priority: Minor
> Labels: code-review
> Fix For: 4.22.0
>
>
> h3. Problem
> {{XsltBuilder.process()}} still carries:
> {code:java}
> // the underlying input stream, which we need to close to avoid locking files or other resources
> InputStream is = null;
> try {
> Source source = getSourceHandlerFactory().getSource(exchange, this.source);
> ...
> } finally {
> releaseTransformer(transformer);
> // IOHelper can handle if null
> IOHelper.close(is); // 'is' is always null
> }
> {code}
> Before CAMEL-13851 (3.0, refactoring that introduced {{SourceHandlerFactory}}), {{is}} was assigned from the body conversion and closed in {{finally}} - the comment documents the file-locking problem that close prevented. Since the refactoring the variable is never assigned, so the close logic is dead and the comment misleadingly implies protection that is not there.
> h3. Verified impact
> Probed empirically on current main with a close-tracking InputStream body through both {{xslt:}} and {{xslt-saxon:}}, for both a successful transform and a parse failure: in all four cases the SAX/StAX parser chain closes the stream, so there is *no observed leak on the standard paths*. The residual risk is limited to exotic paths where an exception fires after source creation but before the parser consumes the stream. Filed as cleanup, not as an active defect.
> h3. Fix direction
> Either restore real close semantics (close the stream/reader backing the created {{Source}} in the {{finally}} block) or remove the dead variable and the stale comment.
> ----
> _This issue was researched and filed by Claude Code on behalf of [~fmariani] (GitHub: Croway), as part of a code review of camel-xslt and camel-xslt-saxon._
--
This message was sent by Atlassian Jira
(v8.20.10#820010)