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


Remko 

(Shameless plug) Every java main() method deserves http://picocli.info

> On Sep 25, 2017, at 8:57, Ralph Goers <[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]>
>> Subject: Re: log4j-to-slf4j
>> Date: September 24, 2017 at 4:27:59 PM MST
>> To: [email protected]
>> Reply-To: [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]> 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
>> 
> 

Reply via email to