aber4mx opened a new issue, #4019: URL: https://github.com/apache/logging-log4j2/issues/4019
## Description Log4j 2's Pattern Layout allows to log Throwables. Several configuration elements allow to configure how the exception stack trace should be logged (max number of lines, package filtering..). However the default behavior without advanced configuration should be to print the stacktrace "as is". It is mentionned in the documentation: `If this mode is employed without any configuration, the output will be identical to the one obtained from Throwable#printStackTrace().` and it was working as of 2.24.3, but the behavior changed in 2.25.3. On a standard Exception, the logged stacktrace is the same. However Exceptions can override the `Throwable#toString()` method which is used by `Throwable#printStackTrace()` or they could also override `Throwable#printStackTrace()` directly. Since 2.25.x, log4j emulates `Throwable#printStackTrace()`, even if there is no advanced paramater that justifies it. By upgrading from 2.24.3 the exceptions logged in our application lose some information and meaning. Could we stick to use `Throwable#toString()` in the default case ? And in the advanced case where that requires cusomization on the StackTraceElements, rather use `Throwable#toString()` for the message part instead of a hard-coded `"throwable.getClass().getName()" + ": " + throwable.getLocalizedMessage()` ? I attach a patch with a unit test that is green at 2.24.3 but is red at 2.25.3 ## Configuration **Version:** 2.25.3 **Operating system:** windows 11 / RedHat 9 **JDK:** OpenJDK 17.0.2 ## Logs See reproduction scenario ## Reproduction The below patch adds a unit test red on 2.25.3, but green on 2.24.3. The unit test logs a custom exception whose class overrides the toString method [exception_rendering_test.patch](https://github.com/user-attachments/files/24410476/exception_rendering_test.patch) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
