Would it be possible to make a log4j-api provider that binds directly to logback instead?
On 25 September 2017 at 18:54, Ralph Goers <[email protected]> wrote: > 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 > >>>>> > >>>> > >> > > > > -- Matt Sicker <[email protected]>
