Log4j2 - Ignores %line and incorrect logger name

Question

Log4j2 - Ignores %line and incorrect logger name

MosheElisha opened this issue 4 years ago · comments

Hi,

Thank you for adding log4j2 support.

When trying to use v 0.5 with the attached line-number-test.zip I see the following output:

2020-03-25T00:26:20,476 [main] INFO  example.LogTest:INFO in 18b4aac2: - Info
2020-03-25T00:26:20,484 [main] WARN  example.LogTest:INFO in 18b4aac2: - Warn
2020-03-25T00:26:20,484 [main] ERROR example.LogTest:INFO in 18b4aac2: - Severe

The Logger name is incorrect (should be example.LogTest instead of example.LogTest:INFO in 18b4aac2
The line number is missing from the message although pattern contains %line . I noticed there is an internal Option.WITH_LOG_SITE but couldn't find a way to influence that and I would expect that having %line would be sufficient.

David Beaumont · Answer 1 · Wed Mar 25 2020 11:01:57 GMT+0800 (China Standard Time)

You've already raised this.

Moshe Elisha · Answer 2 · Wed Mar 25 2020 15:10:09 GMT+0800 (China Standard Time)

Hi,

I was under the impression that it is different because here I am using the log4j2 backend directly (flogger-log4j2-backend). The attached project is also different from the project attached in issue #140

David Beaumont · Answer 3 · Wed Mar 25 2020 18:08:34 GMT+0800 (China Standard Time)

True, but fixing one will inevitably fix the other. SLF4J + log4J2 backend is going to be almost exactly the same same code, just with a very thin layer in SLF4J. To be honest I'd rather we didn't even have and SLF4J "backend" (since SLF4J is not a logging backend API).

Moshe Elisha · Answer 4 · Wed Mar 25 2020 19:04:38 GMT+0800 (China Standard Time)

True, but fixing one will inevitably fix the other

OK. Thanks for the clarification.

To be honest I'd rather we didn't even have and SLF4J "backend"

Yes, I see your point. A direct backend is obviously preferable but on the other hand, "SLF4J backend" acts as a bridge to many popular backends as most of the logging frameworks already have an slf4j adapter. It can be very helpful. At lease until a proper specific backend will be implemented.

David Beaumont · Answer 5 · Wed Mar 25 2020 22:09:37 GMT+0800 (China Standard Time)

The issue is that if there SLF4J API was not written to expect to be called from another logging API we might never be able to address things like the line number issue when using it.

My gut feeling is that JDK and Log4J2 between them will be the vast majority of cases. I'm much less inclined to spend time on Log4J (v1) and SLF4J when it comes to features and bugs (diminishing returns) but I'd always be grateful for fixes if other people want to make them.