YanivKunda commented on issue #3473: URL: https://github.com/apache/logging-log4j2/issues/3473#issuecomment-2693751438
> As a consequence, when LogBuilder came along we decided to be explicit about when a throwable will be treated as a throwable - i.e - only when withThrowable is specified. Does it mean that `Message.getThrowable()` is going to get deprecated? What abou this last-param-analysis logic? I assume it is going to remain as-is for backward-compatibility. I found 3 `Message` implementations that use it for their `throwable` field: 1. `MessageFormatMessage` 2. `ParameterizedMessage` 3. `StringFormattedMessage` I'm not sure that my suggestion causes this unwanted compatibility to persist - it's just a fallback mechanism to the Message's throwable. I understand wanting to keep the API cleaner with less "magic" happening or not in different implementation. However, I originally raised this as an issue with `log4j-transform`, which converts regular logger calls to LogBuilder, and it would be much harder to support this logic there - it might need to infer which mesage implementation is going to be used, and emulate it or delegate to it somehow in order to extract the throwable if applicable. Can you suggest any workaround that doesn't involve converting all existing logger calls to use explicit Message instances or convert to LogBuilder? -- 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: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
