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)