Federico Mariani created CAMEL-24111:
----------------------------------------
Summary: 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
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)
