[
https://issues.apache.org/jira/browse/CAMEL-24567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18109700#comment-18109700
]
mayur mohan commented on CAMEL-24567:
-------------------------------------
Fix implemented in PR https://github.com/apache/camel/pull/25907
One-line null-guard fix in MailConsumer.poll() finally catch block. Full
camel-mail test suite passes with JDK 21.
_Claude Code on behalf of mayurbm_
> camel-mail: MailConsumer.poll() finally catch block uses folder.getName()
> without null check
> --------------------------------------------------------------------------------------------
>
> Key: CAMEL-24567
> URL: https://issues.apache.org/jira/browse/CAMEL-24567
> Project: Camel
> Issue Type: Bug
> Components: camel-mail
> Reporter: mayur mohan
> Priority: Minor
>
> In MailConsumer.poll(), the finally block closes the folder when closeFolder
> or disconnect=true. The close is guarded by a null check:
> {code:java}
> if (folder != null && folder.isOpen()) {
> folder.close(true);
> } catch (Exception e) {
> // CAMEL-1263
> LOG.debug("Could not close mailbox folder: {}...", folder.getName(), e);
> // NPE if folder is null
> }
> {code}
> If folder.close() throws AND folder has been set to null by a concurrent
> disconnect() between the null-check guard and the catch body, the LOG.debug
> call will NPE because folder.getName() is called on a null reference.
> *Stack trace scenario:*
> {noformat}
> java.lang.NullPointerException: Cannot invoke "jakarta.mail.Folder.getName()"
> because "this.folder" is null
> at
> org.apache.camel.component.mail.MailConsumer.poll(MailConsumer.java:193)
> at
> org.apache.camel.support.ScheduledPollConsumer.doRun(ScheduledPollConsumer.java:207)
> at
> org.apache.camel.pollconsumer.quartz.QuartzScheduledPollConsumerJob.execute(...)
> {noformat}
> *Fix:* Use a null-safe expression in the log call:
> {code:java}
> LOG.debug("Could not close mailbox folder: {}...", folder != null ?
> folder.getName() : "null", e);
> {code}
> This is a one-line defensive fix. The probability is low (requires
> folder.close() to throw AND concurrent disconnect() to null the field in the
> same instant) but the fix is trivial and clearly correct.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
