You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by Ralph Goers <ra...@dslextreme.com> on 2017/09/24 22:16:33 UTC
log4j-to-slf4j
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
Re: log4j-to-slf4j
Posted by Matt Sicker <bo...@gmail.com>.
It would be impossible to support Logback without pulling in slf4j-api, and
the extra jars is what causes the perception of a problem.
On 26 September 2017 at 03:20, Remko Popma <re...@gmail.com> wrote:
> Sounds to me that Ralph's analysis shows that doing the binding ourselves
> may not be worth doing since we can't get an advantage by either improving
> people's perception nor improve performance. Unless I'm missing something.
>
>
>
> > On Sep 26, 2017, at 16:34, Mikael Ståldal <mi...@apache.org> wrote:
> >
> > I don't think we should support binding to Logback specifically. We
> should support binding to any SLF4J implementation (including Logback). We
> should probably test this with Logback though, since it's one of the most
> popular SLF4J implementations.
> >
> >
> >> On 2017-09-26 03:58, Matt Sicker wrote:
> >> Would it be possible to make a log4j-api provider that binds directly to
> >> logback instead?
>
--
Matt Sicker <bo...@gmail.com>
Re: log4j-to-slf4j
Posted by Remko Popma <re...@gmail.com>.
Sounds to me that Ralph's analysis shows that doing the binding ourselves may not be worth doing since we can't get an advantage by either improving people's perception nor improve performance. Unless I'm missing something.
> On Sep 26, 2017, at 16:34, Mikael Ståldal <mi...@apache.org> wrote:
>
> I don't think we should support binding to Logback specifically. We should support binding to any SLF4J implementation (including Logback). We should probably test this with Logback though, since it's one of the most popular SLF4J implementations.
>
>
>> On 2017-09-26 03:58, Matt Sicker wrote:
>> Would it be possible to make a log4j-api provider that binds directly to
>> logback instead?
Re: log4j-to-slf4j
Posted by Mikael Ståldal <mi...@apache.org>.
I don't think we should support binding to Logback specifically. We
should support binding to any SLF4J implementation (including Logback).
We should probably test this with Logback though, since it's one of the
most popular SLF4J implementations.
On 2017-09-26 03:58, Matt Sicker wrote:
> Would it be possible to make a log4j-api provider that binds directly to
> logback instead?
Re: log4j-to-slf4j
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <bo...@gmail.com> 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 <ra...@dslextreme.com>
> 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 <re...@gmail.com> 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 <ra...@dslextreme.com>
>> 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 <re...@gmail.com>
>> 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 <ralph.goers@dslextreme.com
>> <ma...@dslextreme.com>> 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 <remko.popma@gmail.com <mailto:
>> remko.popma@gmail.com>>
>>>>>>> Subject: Re: log4j-to-slf4j
>>>>>>> Date: September 24, 2017 at 4:27:59 PM MST
>>>>>>> To: dev@logging.apache.org <ma...@logging.apache.org>
>>>>>>> Reply-To: dev@logging.apache.org <ma...@logging.apache.org>
>>>>>>>
>>>>>>> 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 <ralph.goers@dslextreme.com
>> <ma...@dslextreme.com>> 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 <bo...@gmail.com>
Re: log4j-to-slf4j
Posted by Matt Sicker <bo...@gmail.com>.
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 <ra...@dslextreme.com>
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 <re...@gmail.com> 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 <ra...@dslextreme.com>
> 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 <re...@gmail.com>
> 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 <ralph.goers@dslextreme.com
> <ma...@dslextreme.com>> 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 <remko.popma@gmail.com <mailto:
> remko.popma@gmail.com>>
> >>>>> Subject: Re: log4j-to-slf4j
> >>>>> Date: September 24, 2017 at 4:27:59 PM MST
> >>>>> To: dev@logging.apache.org <ma...@logging.apache.org>
> >>>>> Reply-To: dev@logging.apache.org <ma...@logging.apache.org>
> >>>>>
> >>>>> 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 <ralph.goers@dslextreme.com
> <ma...@dslextreme.com>> 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 <bo...@gmail.com>
Re: log4j-to-slf4j
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <re...@gmail.com> 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 <ra...@dslextreme.com> 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 <re...@gmail.com> 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 <ralph.goers@dslextreme.com <ma...@dslextreme.com>> 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 <remko.popma@gmail.com <ma...@gmail.com>>
>>>>> Subject: Re: log4j-to-slf4j
>>>>> Date: September 24, 2017 at 4:27:59 PM MST
>>>>> To: dev@logging.apache.org <ma...@logging.apache.org>
>>>>> Reply-To: dev@logging.apache.org <ma...@logging.apache.org>
>>>>>
>>>>> 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 <ralph.goers@dslextreme.com <ma...@dslextreme.com>> 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
>>>>>
>>>>
>>
>
Re: log4j-to-slf4j
Posted by Remko Popma <re...@gmail.com>.
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 <ra...@dslextreme.com> 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 <re...@gmail.com> 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 <ralph.goers@dslextreme.com <ma...@dslextreme.com>> 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 <remko.popma@gmail.com <ma...@gmail.com>>
>>>> Subject: Re: log4j-to-slf4j
>>>> Date: September 24, 2017 at 4:27:59 PM MST
>>>> To: dev@logging.apache.org <ma...@logging.apache.org>
>>>> Reply-To: dev@logging.apache.org <ma...@logging.apache.org>
>>>>
>>>> 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 <ralph.goers@dslextreme.com <ma...@dslextreme.com>> 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
>>>>
>>>
>
Re: log4j-to-slf4j
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <re...@gmail.com> 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 <ralph.goers@dslextreme.com <ma...@dslextreme.com>> 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 <remko.popma@gmail.com <ma...@gmail.com>>
>>> Subject: Re: log4j-to-slf4j
>>> Date: September 24, 2017 at 4:27:59 PM MST
>>> To: dev@logging.apache.org <ma...@logging.apache.org>
>>> Reply-To: dev@logging.apache.org <ma...@logging.apache.org>
>>>
>>> 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 <ralph.goers@dslextreme.com <ma...@dslextreme.com>> 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
>>>
>>
Re: log4j-to-slf4j
Posted by Remko Popma <re...@gmail.com>.
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 <ra...@dslextreme.com> 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 <re...@gmail.com>
>> Subject: Re: log4j-to-slf4j
>> Date: September 24, 2017 at 4:27:59 PM MST
>> To: dev@logging.apache.org
>> Reply-To: dev@logging.apache.org
>>
>> 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 <ra...@dslextreme.com> 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
>>
>
Fwd: log4j-to-slf4j
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <re...@gmail.com>
> Subject: Re: log4j-to-slf4j
> Date: September 24, 2017 at 4:27:59 PM MST
> To: dev@logging.apache.org
> Reply-To: dev@logging.apache.org
>
> 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 <ra...@dslextreme.com> 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
>
Re: log4j-to-slf4j
Posted by Remko Popma <re...@gmail.com>.
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 <ra...@dslextreme.com> 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