[ 
https://issues.apache.org/jira/browse/LOG4J2-1409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma updated LOG4J2-1409:
--------------------------------
    Description: 
A specific set of parameterised logging messages produces an Array Index Out of 
Bounds exception. It occurs due to the params array (initially set to 10) being 
reset to a lower number due to a lambda function passed in as an parameter. 
Then the subsequent logging messages don't reset this number.

Best to explain in an example:

{code}
    static Logger logger = LogManager.getLogger();

    public static void main(String[] args) {
        logger.info("Hello {} {} {}", 1, 2,3);
        logger.info("Hello {}", () -> "World");
        logger.info("Hello {}", 1);
        
        // Uncomment out this log event and the params gets reset correctly
        // No exception occurs
        // logger.info("Hello {}", 1);

        // Exception at this log event - as the params is set to 1!
        logger.info("Hello {} {} {}", 1, 2,3);
    }
{code}

Work around for this is not to use the ReusableParameterizedMessage. Instead to 
specify the legacy Message Factory of ParameterizedMessageFactory as a property 
of the program and no exception occurs.


  was:
A specific set of parameterised logging messages produces an Array Index Out of 
Bounds exception. It occurs due to the params array (initially set to 10) being 
reset to a lower number due to a lambda function passed in as an parameter. 
Then the subsequent logging messages don't reset this number.

Best to explain in an example:

    static Logger logger = LogManager.getLogger();

    public static void main(String[] args) {
        logger.info("Hello {} {} {}", 1, 2,3);
        logger.info("Hello {}", () -> "World");
        logger.info("Hello {}", 1);
        
        // Uncomment out this log event and the params gets reset correctly
        // No exception occurs
        // logger.info("Hello {}", 1);

        // Exception at this log event - as the params is set to 1!
        logger.info("Hello {} {} {}", 1, 2,3);
    }

Work around for this is not to use the ReusableParameterizedMessage. Instead to 
specify the legacy Message Factory of ParameterizedMessageFactory as a property 
of the program and no exception occurs.



Thanks for reporting this! Looking into it.

> ArrayIndexOutOfBoundsException in ReusableParameterizedMessage 
> ---------------------------------------------------------------
>
>                 Key: LOG4J2-1409
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-1409
>             Project: Log4j 2
>          Issue Type: Bug
>          Components: API, Core
>    Affects Versions: 2.6
>            Reporter: Shahan
>            Assignee: Remko Popma
>            Priority: Critical
>
> A specific set of parameterised logging messages produces an Array Index Out 
> of Bounds exception. It occurs due to the params array (initially set to 10) 
> being reset to a lower number due to a lambda function passed in as an 
> parameter. Then the subsequent logging messages don't reset this number.
> Best to explain in an example:
> {code}
>     static Logger logger = LogManager.getLogger();
>     public static void main(String[] args) {
>         logger.info("Hello {} {} {}", 1, 2,3);
>         logger.info("Hello {}", () -> "World");
>         logger.info("Hello {}", 1);
>         
>         // Uncomment out this log event and the params gets reset correctly
>         // No exception occurs
>         // logger.info("Hello {}", 1);
>         // Exception at this log event - as the params is set to 1!
>         logger.info("Hello {} {} {}", 1, 2,3);
>     }
> {code}
> Work around for this is not to use the ReusableParameterizedMessage. Instead 
> to specify the legacy Message Factory of ParameterizedMessageFactory as a 
> property of the program and no exception occurs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to