YanivKunda opened a new issue, #169:
URL: https://github.com/apache/logging-log4j-transform/issues/169
In a simple use case, e.g.:
```
logger.error("Hello, {}!", "Problem", new Exception("Oh oh"));
```
Without the transform plugin, the default parameterized message formatter
captures the last argument as a throwable -
if it's the last argument and the previous argument count match the
placeholder count.
When processed by the `ExtendedThrowablePatternConverter`, it is fetched -
from `LogEvent.getThrown()`, which was previously populated when the
LogEvent was created, from `Message.getThrowable()`.
This provides the throwable pattern converter the information to format the
throwable as a message/stacktrace.
Here is the code generated by the transform plugin:
```
Logger var10000 = logger;
Object log4j2$$p0 = new Exception("Oh oh");
Object log4j2$$p1 = "Problem";
Object log4j2$$p2 = "Hello, {}!";
var10000.atError().withLocation(Cache.locations[0]).log(log4j2$$p2,
log4j2$$p1, log4j2$$p0);
```
It create a `LogBuilder`, but does not use its `.withThrowable(Throwable)`
method -
leading to a `LogEvent` that does not have the throwable set.
My thought is that to resolve that, the transform plugin needs - at build
time - to analyze the logger call *in the same way the logger does* to extract
the throwable arg and set it using `.withThrowable(Throwable)`.
An alternative (might be simpler) - is to change the `DefaultLogBuilder` (in
`log4j-api`), so that `DefaultLogBuilder.logMessage(Message)` changes from
```
logger.logMessage(level, marker, fqcn, location, message,
throwable);
```
to something like
```
logger.logMessage(level, marker, fqcn, location, message,
throwable != null ? throwable : message.getThrowable());
```
--
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]
