Understood about the log4j-to-slf4j diagram. About updating the performance page, I haven't been able to spend much time on Log4j2 recently. When I did have time it has gone mostly into bug fixes.
If you have done this before you probably know this, but doing these performance investigations easily take weeks of work. Every time I do this I have multiple cycles of test design, set up, execution, gathering results, analyzing the results, discovering a problem and starting again from scratch. :-) With that in mind I hope you understand that competitors like Logback improving their product is not a great motivator for me to undertake this work. I'm not averse to doing this work, I like it, but it should be driven by advances in Log4j2 in my opinion. The Java 9 stackwalker performance would be interesting to document though, so I am sure I will get around to it at some point. Remko > On Sep 25, 2017, at 14:33, Ralph Goers <[email protected]> wrote: > > Yes, that is what we would want to do. > > BTW - I mentioned it a while ago but is there any chance we can get updated > performance charts? The charts are for Log4j 2.6 vs Logback 1.1.7. Logback > is now at 1.1.11 and 1.2.3. I am not really clear on what is different > between 1.1.x and 1.2.x. > > Ralph > >> On Sep 24, 2017, at 9:50 PM, Remko Popma <[email protected]> wrote: >> >> Ok I see now. >> It would certainly be good to have more ammunition to argue for using the >> Log4j2 API directly. >> >> Comments on StackOverflow >> https://stackoverflow.com/a/41500347/1446916 >> <https://stackoverflow.com/a/41500347/1446916> show some people perceive the >> log4j-to-slf4j module as a facade for a facade. >> >> If we bind directly, perhaps I should update this diagram to have a direct >> arrow from log4j-to-slf4j to SLF4J implementation? >> <image1.png> >> >> Remko >> >> (Shameless plug) Every java main() method deserves http://picocli.info >> <http://picocli.info/> >> >>> On Sep 25, 2017, at 8:57, Ralph Goers <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Well, SLF4J recently changed the binding mechanism with 1.8 in order to >>> comply with Java 9. It isn’t likely to do it again any time soon. >>> >>> What we would “solve” is that now it is log4j-api -> log4j-to-slf4j -> >>> slf4j-api -> logging implementation. With this change it would be >>> log4j-api -> log4j-slf4j-binding -> logging implementation. I see 2 >>> advantages to this: >>> 1. It would be harder to say that the log4j-api isn’t appropriate to be the >>> logging API since the binding to SLF4J implementations would be very light. >>> 2. The code path to get to an SLF4J implementation would be shorter. >>> >>> To be honest, item 1 is the one I find more appealing. It reminds me of how >>> OS/2’s support for Windows was not what people really wanted vs the way >>> Windows NT handled it. >>> >>> Ralph >>> >>>> Begin forwarded message: >>>> >>>> From: Remko Popma <[email protected] <mailto:[email protected]>> >>>> Subject: Re: log4j-to-slf4j >>>> Date: September 24, 2017 at 4:27:59 PM MST >>>> To: [email protected] <mailto:[email protected]> >>>> Reply-To: [email protected] <mailto:[email protected]> >>>> >>>> That's certainly possible. >>>> The trade off is that we'd need to track the SLF4J binding mechanism and >>>> update our implementation when this binding mechanism changes. >>>> >>>> What problem are we trying to solve? >>>> >>>> Remko >>>> >>>>> On Sep 25, 2017, at 7:16, Ralph Goers <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>> In looking at the implementations of log4j-slf4j-impl and log4j-to-slf4j >>>>> is strikes me that log4j-to-slf4j is binding to the SLF4J API while >>>>> log4j-slf4j-impl is binding the SFL4J API to the log4j implementation >>>>> using SLF4J’s binding mechanism. So it seems to me that instead of having >>>>> log4j-to-slf4j call the SLF4J API we ought to be able to have it call the >>>>> SLF4J bindings and completely bypass SLF4J itself. Some user’s might find >>>>> this more palatable as it would remove one layer between the Log4j API >>>>> and whatever logging implementation the user chose. >>>>> >>>>> Thoughts? >>>>> >>>>> Ralph >>>> >>> >
