Yes, I started doing that when I realized it didn’t solve anything. We still would require the slf4j-api jar to get the interfaces and MDC unless we were to use Reflection, which I think would be a very bad idea. So the perception would still be there that there is extra overhead.
Ralph > On Sep 25, 2017, at 6:58 PM, Matt Sicker <[email protected]> wrote: > > 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]>
