I have been looking at the log4j-to-slf4j binding and am rethinking changing it. There really isn’t much to SLF4J to begin with. Unlike Log4j 2, Logger is an interface; the whole implementation is delegated. All SLF4J really does is perform the binding between it and the implementation. So what really happens with our binding is: When LogManager.getLogger() is first called log4j-to-slf4j provides the Log4j API’s logging implementation. That implementation will call SLF4J’s LogFactory.getLogger() which will cause SLF4J to bind to its implementation. We then create a Logger adapter that implements our Logger API but then wraps an SLF4J implementation’s Logger. We don’t actually know what that is because we are using the SLF4J Logger interface. When a Logging call is made the Log4j API will call the Logger Adapter which will in turn call the SLF4J logging implementation.
There is no way to remove the dependency on the slf4j-api jar because it is required to use the interfaces. Since the slf4j jar is required there doesn’t seem to be much point in reimplementing SLF4J’s binding logic. But the most important point is that when performing logging the picture really is: Log4j API -> log4j-slf4j adapter ->. SLF4J logging implementation. In other words, SLF4J isn’t even in the picture at that point. I think we should make that clear in the documentation. I can’t seem to come up with any ideas on how to make it simpler than this. Ralph > On Sep 25, 2017, at 6:12 AM, Remko Popma <[email protected]> wrote: > > 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 >>>>> >>>> >> >
