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 >>> >>
