[ 
https://issues.apache.org/jira/browse/CAMEL-24111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18096835#comment-18096835
 ] 

Claus Ibsen commented on CAMEL-24111:
-------------------------------------

Fixed via https://github.com/apache/camel/pull/24780

> 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)

Reply via email to