[jira] [Created] (CAMEL-24567) camel-mail: MailConsumer.poll() finally catch block uses folder.getName() without null check

[mayur mohan (Jira)]

mayur mohan created CAMEL-24567:
-----------------------------------

             Summary: 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


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)