You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Oleg Kalnichevski <ol...@apache.org> on 2017/12/01 09:09:05 UTC
Using SLF4J as a logging facade; Re: Disagreement on Log4J2
Folks
It is going to be unpleasant but we need to revisit a highly
contentious issue of the choice of a logging APIs for HttpClient 5.0.
I personally like Log4J2 and generally am a satisfied user of the
toolkit. However, Log4J2 logging facade APIs did accumulate a lot of
stuff that in my opinion should not have been there in the first place.
This bothers me.
A more immediate problem with Log4J2, though, is that its logging APIs
do not play nicely with Android. Whether or not this is Log4J2 fault is
not for me to say but presently HttpClient 5.0 is incompatible with
Android due to its dependency on Log4J2 logging APIs. It is also
unclear whether this incompatibility could be resolved and when. See LO
G4J2-2133 [1] for details.
At this point while HttpClient 5.0 is still ALPHA we could switch to
SLF4J and personally think we should. Log4J2 would still be the
preferred and the default toolkit for HttpClient 5.0 though the logging
interface would be SLF4J, not Log4J2 logging APIs.
Please share your thoughts.
Oleg
[1] https://issues.apache.org/jira/browse/LOG4J2-2133
On Wed, 2017-05-03 at 11:19 +0200, Michael Osipov wrote:
> Hi folks,
>
> it recently has come to my attention that Commons Logging has been
> replaced with Log4J2. Well, I proposed almost two years ago to move
> to
> SLF4J for good reasons [1].
> People disagreed that Commons Logging is good enough and this
> discussion
> has been held several times w/o any concensus. Since people also
> disgreed this time, I obstained to changed the code even if I
> disagree
> with the consent.
>
> Some time back Oleg raised the same question on the dev mailing list
> [2]. The already existing ticket wasn't even put into consideration
> to
> inform all subscribers. Some discussion was held on the mailing
> list.
> The ticket [3] was created w/o any proper description, proposal and
> linking to any concensus and boom, a day later it was committed.
>
> As Oleg expressed here [4] a lot of users will be pissed off why
> they
> need now a new facade for a facade to do logging. Infact, as for the
> facade all/some the improvements could have landed in SLF4J after
> all.
>
> If someone wants to use Log4J2 as a logging backend that's perfectly
> fine.
>
> I am not really satisfied with the course of discussion and
> documentation of this change. It could have been way better and will
> leave a bad aftertaste. After all, the issue (list) should contain
> all
> necessary information why a change was done. It simple hasn't been
> done.
> I don't expect any client who is upgrading to search mailing lists
> for
> such answers.
>
> At the end, people will add exclusions to their POM, add the SLF4J
> bridge and log to whatever they want.
>
> Michael
>
> [1] https://issues.apache.org/jira/browse/HTTPCLIENT-1664
> [2] http://www.mail-archive.com/dev@hc.apache.org/msg16743.html
> [3] https://issues.apache.org/jira/browse/HTTPCLIENT-1786
> [4] http://www.mail-archive.com/dev@hc.apache.org/msg17847.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Using SLF4J as a logging facade; Re: Disagreement on Log4J2
Posted by Gary Gregory <ga...@gmail.com>.
You are going to have the same problem with Slf4j 1.8 IIRC.
Gary
On Fri, Dec 1, 2017 at 2:09 AM, Oleg Kalnichevski <ol...@apache.org> wrote:
> Folks
>
> It is going to be unpleasant but we need to revisit a highly
> contentious issue of the choice of a logging APIs for HttpClient 5.0.
>
> I personally like Log4J2 and generally am a satisfied user of the
> toolkit. However, Log4J2 logging facade APIs did accumulate a lot of
> stuff that in my opinion should not have been there in the first place.
> This bothers me.
>
> A more immediate problem with Log4J2, though, is that its logging APIs
> do not play nicely with Android. Whether or not this is Log4J2 fault is
> not for me to say but presently HttpClient 5.0 is incompatible with
> Android due to its dependency on Log4J2 logging APIs. It is also
> unclear whether this incompatibility could be resolved and when. See LO
> G4J2-2133 [1] for details.
>
> At this point while HttpClient 5.0 is still ALPHA we could switch to
> SLF4J and personally think we should. Log4J2 would still be the
> preferred and the default toolkit for HttpClient 5.0 though the logging
> interface would be SLF4J, not Log4J2 logging APIs.
>
> Please share your thoughts.
>
> Oleg
>
> [1] https://issues.apache.org/jira/browse/LOG4J2-2133
>
>
> On Wed, 2017-05-03 at 11:19 +0200, Michael Osipov wrote:
> > Hi folks,
> >
> > it recently has come to my attention that Commons Logging has been
> > replaced with Log4J2. Well, I proposed almost two years ago to move
> > to
> > SLF4J for good reasons [1].
> > People disagreed that Commons Logging is good enough and this
> > discussion
> > has been held several times w/o any concensus. Since people also
> > disgreed this time, I obstained to changed the code even if I
> > disagree
> > with the consent.
> >
> > Some time back Oleg raised the same question on the dev mailing list
> > [2]. The already existing ticket wasn't even put into consideration
> > to
> > inform all subscribers. Some discussion was held on the mailing
> > list.
> > The ticket [3] was created w/o any proper description, proposal and
> > linking to any concensus and boom, a day later it was committed.
> >
> > As Oleg expressed here [4] a lot of users will be pissed off why
> > they
> > need now a new facade for a facade to do logging. Infact, as for the
> > facade all/some the improvements could have landed in SLF4J after
> > all.
> >
> > If someone wants to use Log4J2 as a logging backend that's perfectly
> > fine.
> >
> > I am not really satisfied with the course of discussion and
> > documentation of this change. It could have been way better and will
> > leave a bad aftertaste. After all, the issue (list) should contain
> > all
> > necessary information why a change was done. It simple hasn't been
> > done.
> > I don't expect any client who is upgrading to search mailing lists
> > for
> > such answers.
> >
> > At the end, people will add exclusions to their POM, add the SLF4J
> > bridge and log to whatever they want.
> >
> > Michael
> >
> > [1] https://issues.apache.org/jira/browse/HTTPCLIENT-1664
> > [2] http://www.mail-archive.com/dev@hc.apache.org/msg16743.html
> > [3] https://issues.apache.org/jira/browse/HTTPCLIENT-1786
> > [4] http://www.mail-archive.com/dev@hc.apache.org/msg17847.html
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > For additional commands, e-mail: dev-help@hc.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>
Re: Using SLF4J as a logging facade; Re: Disagreement on Log4J2
Posted by V Cekvenich <vi...@gmail.com>.
ftw - I'm a user of lib, not a committer.
I want to use as few jars as possible, and log4j2 plain is simpler for me.
Core beta already does it and plan was to do it w/ client beta.
I'm not sure why a new dependency is being added here. Lo4j2 I think can be
used with SLF4J without this project doing anything.
hth
On Wed, Jan 10, 2018 at 9:12 AM, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Wed, 2018-01-10 at 06:53 -0700, Gary Gregory wrote:
> > I am a disappointed but I understand.
> >
> > Gary
> >
>
> Michael
>
> Will this settle the issue for you?
>
> I remember you were also unhappy about a number of other things,
> exception handling being among them. _Now_ would be the time to deal
> with whatever you deem wrong with HC 5.0 APIs.
>
>
> Oleg
>
> > On Jan 10, 2018 01:54, "Oleg Kalnichevski" <ol...@apache.org> wrote:
> >
> > > On Mon, 2018-01-08 at 11:45 +0100, Oleg Kalnichevski wrote:
> > > > On Fri, 2017-12-08 at 22:14 +0100, Michael Osipov wrote:
> > > > > Am 2017-12-01 um 10:09 schrieb Oleg Kalnichevski:
> > > > > > Folks
> > > > > >
> > > > > > It is going to be unpleasant but we need to revisit a highly
> > > > > > contentious issue of the choice of a logging APIs for
> > > > > > HttpClient
> > > > > > 5.0.
> > > > > >
> > > > > > I personally like Log4J2 and generally am a satisfied user of
> > > > > > the
> > > > > > toolkit. However, Log4J2 logging facade APIs did accumulate a
> > > > > > lot
> > > > > > of
> > > > > > stuff that in my opinion should not have been there in the
> > > > > > first
> > > > > > place.
> > > > > > This bothers me.
> > > > > >
> > > > > > A more immediate problem with Log4J2, though, is that its
> > > > > > logging
> > > > > > APIs
> > > > > > do not play nicely with Android. Whether or not this is
> > > > > > Log4J2
> > > > > > fault is
> > > > > > not for me to say but presently HttpClient 5.0 is
> > > > > > incompatible
> > > > > > with
> > > > > > Android due to its dependency on Log4J2 logging APIs. It is
> > > > > > also
> > > > > > unclear whether this incompatibility could be resolved and
> > > > > > when. See LO
> > > > > > G4J2-2133 [1] for details.
> > > > > >
> > > > > > At this point while HttpClient 5.0 is still ALPHA we could
> > > > > > switch
> > > > > > to
> > > > > > SLF4J and personally think we should. Log4J2 would still be
> > > > > > the
> > > > > > preferred and the default toolkit for HttpClient 5.0 though
> > > > > > the
> > > > > > logging
> > > > > > interface would be SLF4J, not Log4J2 logging APIs.
> > > > > >
> > > > > > Please share your thoughts.
> > > > >
> > > > > Have checked the JIRA issue on this and it seems to gain some
> > > > > traction.
> > > > > Moreover on core-libs-dev@openjdk has some discussion about it
> > > > > that
> > > > > Google might/will fix this for d8?
> > > > >
> > > > > For the sake of backwards-compat and less headache, I'd switch
> > > > > to
> > > > > SLF4J.
> > > > > One can still use Log4J2 backend.
> > > > >
> > > > > As for SLF4J 1.8. I don't see HC 5.0 to switch to it to
> > > > > maintain
> > > > > binary
> > > > > compat.
> > > > >
> > > > > Michael
> > > > >
> > > >
> > > > Folks
> > > >
> > > > I hate doing it but we need to make a decision and live with it
> > > > until
> > > > 6.0 ALPHA.
> > > >
> > > > We cannot make everyone happy but using Log4j2 logging backend
> > > > via
> > > > SLF4J facade appears to be the lesser evil and causes the least
> > > > unhappiness among users and committers as well.
> > > >
> > > > @Gary,
> > > > Can you live with that?
> > > >
> > > > @all
> > > > Do we need more discussion? Do we need a formal vote on the
> > > > matter?
> > > >
> > > > Cheers
> > > >
> > > > Oleg
> > >
> > > Given that no one responded I am going to go ahead and put slf4j as
> > > a
> > > facade to log4j2.
> > >
> > > I also realized that we could migrate back to log4j2 logging APIs
> > > in a
> > > minor release (5.1) without breaking binary compatibility.
> > >
> > > Let's revisit this whole thing once it is time to upgrade from Java
> > > 1.7
> > > to Java 1.8 or Java 9.
> > >
> > > Oleg
> > >
> > > -----------------------------------------------------------------
> > > ----
> > > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > > For additional commands, e-mail: dev-help@hc.apache.org
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>
Re: Using SLF4J as a logging facade; Re: Disagreement on Log4J2
Posted by Michael Osipov <mi...@apache.org>.
Am 2018-01-13 um 11:50 schrieb Oleg Kalnichevski:
> On January 13, 2018 11:26:01 AM GMT+01:00, Michael Osipov <mi...@apache.org> wrote:
>> Am 2018-01-10 um 15:12 schrieb Oleg Kalnichevski:
>>> On Wed, 2018-01-10 at 06:53 -0700, Gary Gregory wrote:
>>>> I am a disappointed but I understand.
>>>>
>>>> Gary
>>>>
>>>
>>> Michael
>>>
>>> Will this settle the issue for you?
>>
>> It does, but I rather expected to have a discussion. Not overcome by
>> events of the Android incompat. Though, it should be fine for now.
> There was nothing stopping you from participating, was there? Besides Android compatibility was a manifestation of a larger issue and not the only or the main factor and could have been resolved given a bit of time.
I did start the discussion "Disagreement on Log4J2", but there were no
reactions from the community.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Using SLF4J as a logging facade; Re: Disagreement on Log4J2
Posted by Oleg Kalnichevski <ol...@ok2consulting.com>.
On January 13, 2018 11:26:01 AM GMT+01:00, Michael Osipov <mi...@apache.org> wrote:
>Am 2018-01-10 um 15:12 schrieb Oleg Kalnichevski:
>> On Wed, 2018-01-10 at 06:53 -0700, Gary Gregory wrote:
>>> I am a disappointed but I understand.
>>>
>>> Gary
>>>
>>
>> Michael
>>
>> Will this settle the issue for you?
>
>It does, but I rather expected to have a discussion. Not overcome by
>events of the Android incompat. Though, it should be fine for now.
There was nothing stopping you from participating, was there? Besides Android compatibility was a manifestation of a larger issue and not the only or the main factor and could have been resolved given a bit of time.
Oleg
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Using SLF4J as a logging facade; Re: Disagreement on Log4J2
Posted by Michael Osipov <mi...@apache.org>.
Am 2018-01-10 um 15:12 schrieb Oleg Kalnichevski:
> On Wed, 2018-01-10 at 06:53 -0700, Gary Gregory wrote:
>> I am a disappointed but I understand.
>>
>> Gary
>>
>
> Michael
>
> Will this settle the issue for you?
It does, but I rather expected to have a discussion. Not overcome by
events of the Android incompat. Though, it should be fine for now.
> I remember you were also unhappy about a number of other things,
> exception handling being among them. _Now_ would be the time to deal
> with whatever you deem wrong with HC 5.0 APIs.
I vaguely remember that, you memory serves you better than mine. Can
you point me to the discussion? I will have a look at it.
Michael
> Oleg
>
>> On Jan 10, 2018 01:54, "Oleg Kalnichevski" <ol...@apache.org> wrote:
>>
>>> On Mon, 2018-01-08 at 11:45 +0100, Oleg Kalnichevski wrote:
>>>> On Fri, 2017-12-08 at 22:14 +0100, Michael Osipov wrote:
>>>>> Am 2017-12-01 um 10:09 schrieb Oleg Kalnichevski:
>>>>>> Folks
>>>>>>
>>>>>> It is going to be unpleasant but we need to revisit a highly
>>>>>> contentious issue of the choice of a logging APIs for
>>>>>> HttpClient
>>>>>> 5.0.
>>>>>>
>>>>>> I personally like Log4J2 and generally am a satisfied user of
>>>>>> the
>>>>>> toolkit. However, Log4J2 logging facade APIs did accumulate a
>>>>>> lot
>>>>>> of
>>>>>> stuff that in my opinion should not have been there in the
>>>>>> first
>>>>>> place.
>>>>>> This bothers me.
>>>>>>
>>>>>> A more immediate problem with Log4J2, though, is that its
>>>>>> logging
>>>>>> APIs
>>>>>> do not play nicely with Android. Whether or not this is
>>>>>> Log4J2
>>>>>> fault is
>>>>>> not for me to say but presently HttpClient 5.0 is
>>>>>> incompatible
>>>>>> with
>>>>>> Android due to its dependency on Log4J2 logging APIs. It is
>>>>>> also
>>>>>> unclear whether this incompatibility could be resolved and
>>>>>> when. See LO
>>>>>> G4J2-2133 [1] for details.
>>>>>>
>>>>>> At this point while HttpClient 5.0 is still ALPHA we could
>>>>>> switch
>>>>>> to
>>>>>> SLF4J and personally think we should. Log4J2 would still be
>>>>>> the
>>>>>> preferred and the default toolkit for HttpClient 5.0 though
>>>>>> the
>>>>>> logging
>>>>>> interface would be SLF4J, not Log4J2 logging APIs.
>>>>>>
>>>>>> Please share your thoughts.
>>>>>
>>>>> Have checked the JIRA issue on this and it seems to gain some
>>>>> traction.
>>>>> Moreover on core-libs-dev@openjdk has some discussion about it
>>>>> that
>>>>> Google might/will fix this for d8?
>>>>>
>>>>> For the sake of backwards-compat and less headache, I'd switch
>>>>> to
>>>>> SLF4J.
>>>>> One can still use Log4J2 backend.
>>>>>
>>>>> As for SLF4J 1.8. I don't see HC 5.0 to switch to it to
>>>>> maintain
>>>>> binary
>>>>> compat.
>>>>>
>>>>> Michael
>>>>>
>>>>
>>>> Folks
>>>>
>>>> I hate doing it but we need to make a decision and live with it
>>>> until
>>>> 6.0 ALPHA.
>>>>
>>>> We cannot make everyone happy but using Log4j2 logging backend
>>>> via
>>>> SLF4J facade appears to be the lesser evil and causes the least
>>>> unhappiness among users and committers as well.
>>>>
>>>> @Gary,
>>>> Can you live with that?
>>>>
>>>> @all
>>>> Do we need more discussion? Do we need a formal vote on the
>>>> matter?
>>>>
>>>> Cheers
>>>>
>>>> Oleg
>>>
>>> Given that no one responded I am going to go ahead and put slf4j as
>>> a
>>> facade to log4j2.
>>>
>>> I also realized that we could migrate back to log4j2 logging APIs
>>> in a
>>> minor release (5.1) without breaking binary compatibility.
>>>
>>> Let's revisit this whole thing once it is time to upgrade from Java
>>> 1.7
>>> to Java 1.8 or Java 9.
>>>
>>> Oleg
>>>
>>> -----------------------------------------------------------------
>>> ----
>>> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
>>> For additional commands, e-mail: dev-help@hc.apache.org
>>>
>>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Using SLF4J as a logging facade; Re: Disagreement on Log4J2
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Wed, 2018-01-10 at 06:53 -0700, Gary Gregory wrote:
> I am a disappointed but I understand.
>
> Gary
>
Michael
Will this settle the issue for you?
I remember you were also unhappy about a number of other things,
exception handling being among them. _Now_ would be the time to deal
with whatever you deem wrong with HC 5.0 APIs.
Oleg
> On Jan 10, 2018 01:54, "Oleg Kalnichevski" <ol...@apache.org> wrote:
>
> > On Mon, 2018-01-08 at 11:45 +0100, Oleg Kalnichevski wrote:
> > > On Fri, 2017-12-08 at 22:14 +0100, Michael Osipov wrote:
> > > > Am 2017-12-01 um 10:09 schrieb Oleg Kalnichevski:
> > > > > Folks
> > > > >
> > > > > It is going to be unpleasant but we need to revisit a highly
> > > > > contentious issue of the choice of a logging APIs for
> > > > > HttpClient
> > > > > 5.0.
> > > > >
> > > > > I personally like Log4J2 and generally am a satisfied user of
> > > > > the
> > > > > toolkit. However, Log4J2 logging facade APIs did accumulate a
> > > > > lot
> > > > > of
> > > > > stuff that in my opinion should not have been there in the
> > > > > first
> > > > > place.
> > > > > This bothers me.
> > > > >
> > > > > A more immediate problem with Log4J2, though, is that its
> > > > > logging
> > > > > APIs
> > > > > do not play nicely with Android. Whether or not this is
> > > > > Log4J2
> > > > > fault is
> > > > > not for me to say but presently HttpClient 5.0 is
> > > > > incompatible
> > > > > with
> > > > > Android due to its dependency on Log4J2 logging APIs. It is
> > > > > also
> > > > > unclear whether this incompatibility could be resolved and
> > > > > when. See LO
> > > > > G4J2-2133 [1] for details.
> > > > >
> > > > > At this point while HttpClient 5.0 is still ALPHA we could
> > > > > switch
> > > > > to
> > > > > SLF4J and personally think we should. Log4J2 would still be
> > > > > the
> > > > > preferred and the default toolkit for HttpClient 5.0 though
> > > > > the
> > > > > logging
> > > > > interface would be SLF4J, not Log4J2 logging APIs.
> > > > >
> > > > > Please share your thoughts.
> > > >
> > > > Have checked the JIRA issue on this and it seems to gain some
> > > > traction.
> > > > Moreover on core-libs-dev@openjdk has some discussion about it
> > > > that
> > > > Google might/will fix this for d8?
> > > >
> > > > For the sake of backwards-compat and less headache, I'd switch
> > > > to
> > > > SLF4J.
> > > > One can still use Log4J2 backend.
> > > >
> > > > As for SLF4J 1.8. I don't see HC 5.0 to switch to it to
> > > > maintain
> > > > binary
> > > > compat.
> > > >
> > > > Michael
> > > >
> > >
> > > Folks
> > >
> > > I hate doing it but we need to make a decision and live with it
> > > until
> > > 6.0 ALPHA.
> > >
> > > We cannot make everyone happy but using Log4j2 logging backend
> > > via
> > > SLF4J facade appears to be the lesser evil and causes the least
> > > unhappiness among users and committers as well.
> > >
> > > @Gary,
> > > Can you live with that?
> > >
> > > @all
> > > Do we need more discussion? Do we need a formal vote on the
> > > matter?
> > >
> > > Cheers
> > >
> > > Oleg
> >
> > Given that no one responded I am going to go ahead and put slf4j as
> > a
> > facade to log4j2.
> >
> > I also realized that we could migrate back to log4j2 logging APIs
> > in a
> > minor release (5.1) without breaking binary compatibility.
> >
> > Let's revisit this whole thing once it is time to upgrade from Java
> > 1.7
> > to Java 1.8 or Java 9.
> >
> > Oleg
> >
> > -----------------------------------------------------------------
> > ----
> > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > For additional commands, e-mail: dev-help@hc.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Using SLF4J as a logging facade; Re: Disagreement on Log4J2
Posted by Gary Gregory <ga...@gmail.com>.
I am a disappointed but I understand.
Gary
On Jan 10, 2018 01:54, "Oleg Kalnichevski" <ol...@apache.org> wrote:
> On Mon, 2018-01-08 at 11:45 +0100, Oleg Kalnichevski wrote:
> > On Fri, 2017-12-08 at 22:14 +0100, Michael Osipov wrote:
> > > Am 2017-12-01 um 10:09 schrieb Oleg Kalnichevski:
> > > > Folks
> > > >
> > > > It is going to be unpleasant but we need to revisit a highly
> > > > contentious issue of the choice of a logging APIs for HttpClient
> > > > 5.0.
> > > >
> > > > I personally like Log4J2 and generally am a satisfied user of the
> > > > toolkit. However, Log4J2 logging facade APIs did accumulate a lot
> > > > of
> > > > stuff that in my opinion should not have been there in the first
> > > > place.
> > > > This bothers me.
> > > >
> > > > A more immediate problem with Log4J2, though, is that its logging
> > > > APIs
> > > > do not play nicely with Android. Whether or not this is Log4J2
> > > > fault is
> > > > not for me to say but presently HttpClient 5.0 is incompatible
> > > > with
> > > > Android due to its dependency on Log4J2 logging APIs. It is also
> > > > unclear whether this incompatibility could be resolved and
> > > > when. See LO
> > > > G4J2-2133 [1] for details.
> > > >
> > > > At this point while HttpClient 5.0 is still ALPHA we could switch
> > > > to
> > > > SLF4J and personally think we should. Log4J2 would still be the
> > > > preferred and the default toolkit for HttpClient 5.0 though the
> > > > logging
> > > > interface would be SLF4J, not Log4J2 logging APIs.
> > > >
> > > > Please share your thoughts.
> > >
> > > Have checked the JIRA issue on this and it seems to gain some
> > > traction.
> > > Moreover on core-libs-dev@openjdk has some discussion about it
> > > that
> > > Google might/will fix this for d8?
> > >
> > > For the sake of backwards-compat and less headache, I'd switch to
> > > SLF4J.
> > > One can still use Log4J2 backend.
> > >
> > > As for SLF4J 1.8. I don't see HC 5.0 to switch to it to maintain
> > > binary
> > > compat.
> > >
> > > Michael
> > >
> >
> > Folks
> >
> > I hate doing it but we need to make a decision and live with it until
> > 6.0 ALPHA.
> >
> > We cannot make everyone happy but using Log4j2 logging backend via
> > SLF4J facade appears to be the lesser evil and causes the least
> > unhappiness among users and committers as well.
> >
> > @Gary,
> > Can you live with that?
> >
> > @all
> > Do we need more discussion? Do we need a formal vote on the matter?
> >
> > Cheers
> >
> > Oleg
>
> Given that no one responded I am going to go ahead and put slf4j as a
> facade to log4j2.
>
> I also realized that we could migrate back to log4j2 logging APIs in a
> minor release (5.1) without breaking binary compatibility.
>
> Let's revisit this whole thing once it is time to upgrade from Java 1.7
> to Java 1.8 or Java 9.
>
> Oleg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>
Re: Using SLF4J as a logging facade; Re: Disagreement on Log4J2
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Mon, 2018-01-08 at 11:45 +0100, Oleg Kalnichevski wrote:
> On Fri, 2017-12-08 at 22:14 +0100, Michael Osipov wrote:
> > Am 2017-12-01 um 10:09 schrieb Oleg Kalnichevski:
> > > Folks
> > >
> > > It is going to be unpleasant but we need to revisit a highly
> > > contentious issue of the choice of a logging APIs for HttpClient
> > > 5.0.
> > >
> > > I personally like Log4J2 and generally am a satisfied user of the
> > > toolkit. However, Log4J2 logging facade APIs did accumulate a lot
> > > of
> > > stuff that in my opinion should not have been there in the first
> > > place.
> > > This bothers me.
> > >
> > > A more immediate problem with Log4J2, though, is that its logging
> > > APIs
> > > do not play nicely with Android. Whether or not this is Log4J2
> > > fault is
> > > not for me to say but presently HttpClient 5.0 is incompatible
> > > with
> > > Android due to its dependency on Log4J2 logging APIs. It is also
> > > unclear whether this incompatibility could be resolved and
> > > when. See LO
> > > G4J2-2133 [1] for details.
> > >
> > > At this point while HttpClient 5.0 is still ALPHA we could switch
> > > to
> > > SLF4J and personally think we should. Log4J2 would still be the
> > > preferred and the default toolkit for HttpClient 5.0 though the
> > > logging
> > > interface would be SLF4J, not Log4J2 logging APIs.
> > >
> > > Please share your thoughts.
> >
> > Have checked the JIRA issue on this and it seems to gain some
> > traction.
> > Moreover on core-libs-dev@openjdk has some discussion about it
> > that
> > Google might/will fix this for d8?
> >
> > For the sake of backwards-compat and less headache, I'd switch to
> > SLF4J.
> > One can still use Log4J2 backend.
> >
> > As for SLF4J 1.8. I don't see HC 5.0 to switch to it to maintain
> > binary
> > compat.
> >
> > Michael
> >
>
> Folks
>
> I hate doing it but we need to make a decision and live with it until
> 6.0 ALPHA.
>
> We cannot make everyone happy but using Log4j2 logging backend via
> SLF4J facade appears to be the lesser evil and causes the least
> unhappiness among users and committers as well.
>
> @Gary,
> Can you live with that?
>
> @all
> Do we need more discussion? Do we need a formal vote on the matter?
>
> Cheers
>
> Oleg
Given that no one responded I am going to go ahead and put slf4j as a
facade to log4j2.
I also realized that we could migrate back to log4j2 logging APIs in a
minor release (5.1) without breaking binary compatibility.
Let's revisit this whole thing once it is time to upgrade from Java 1.7
to Java 1.8 or Java 9.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Using SLF4J as a logging facade; Re: Disagreement on Log4J2
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, 2017-12-08 at 22:14 +0100, Michael Osipov wrote:
> Am 2017-12-01 um 10:09 schrieb Oleg Kalnichevski:
> > Folks
> >
> > It is going to be unpleasant but we need to revisit a highly
> > contentious issue of the choice of a logging APIs for HttpClient
> > 5.0.
> >
> > I personally like Log4J2 and generally am a satisfied user of the
> > toolkit. However, Log4J2 logging facade APIs did accumulate a lot
> > of
> > stuff that in my opinion should not have been there in the first
> > place.
> > This bothers me.
> >
> > A more immediate problem with Log4J2, though, is that its logging
> > APIs
> > do not play nicely with Android. Whether or not this is Log4J2
> > fault is
> > not for me to say but presently HttpClient 5.0 is incompatible with
> > Android due to its dependency on Log4J2 logging APIs. It is also
> > unclear whether this incompatibility could be resolved and
> > when. See LO
> > G4J2-2133 [1] for details.
> >
> > At this point while HttpClient 5.0 is still ALPHA we could switch
> > to
> > SLF4J and personally think we should. Log4J2 would still be the
> > preferred and the default toolkit for HttpClient 5.0 though the
> > logging
> > interface would be SLF4J, not Log4J2 logging APIs.
> >
> > Please share your thoughts.
>
> Have checked the JIRA issue on this and it seems to gain some
> traction.
> Moreover on core-libs-dev@openjdk has some discussion about it that
> Google might/will fix this for d8?
>
> For the sake of backwards-compat and less headache, I'd switch to
> SLF4J.
> One can still use Log4J2 backend.
>
> As for SLF4J 1.8. I don't see HC 5.0 to switch to it to maintain
> binary
> compat.
>
> Michael
>
Folks
I hate doing it but we need to make a decision and live with it until
6.0 ALPHA.
We cannot make everyone happy but using Log4j2 logging backend via
SLF4J facade appears to be the lesser evil and causes the least
unhappiness among users and committers as well.
@Gary,
Can you live with that?
@all
Do we need more discussion? Do we need a formal vote on the matter?
Cheers
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Using SLF4J as a logging facade; Re: Disagreement on Log4J2
Posted by Michael Osipov <mi...@apache.org>.
Am 2017-12-01 um 10:09 schrieb Oleg Kalnichevski:
> Folks
>
> It is going to be unpleasant but we need to revisit a highly
> contentious issue of the choice of a logging APIs for HttpClient 5.0.
>
> I personally like Log4J2 and generally am a satisfied user of the
> toolkit. However, Log4J2 logging facade APIs did accumulate a lot of
> stuff that in my opinion should not have been there in the first place.
> This bothers me.
>
> A more immediate problem with Log4J2, though, is that its logging APIs
> do not play nicely with Android. Whether or not this is Log4J2 fault is
> not for me to say but presently HttpClient 5.0 is incompatible with
> Android due to its dependency on Log4J2 logging APIs. It is also
> unclear whether this incompatibility could be resolved and when. See LO
> G4J2-2133 [1] for details.
>
> At this point while HttpClient 5.0 is still ALPHA we could switch to
> SLF4J and personally think we should. Log4J2 would still be the
> preferred and the default toolkit for HttpClient 5.0 though the logging
> interface would be SLF4J, not Log4J2 logging APIs.
>
> Please share your thoughts.
Have checked the JIRA issue on this and it seems to gain some traction.
Moreover on core-libs-dev@openjdk has some discussion about it that
Google might/will fix this for d8?
For the sake of backwards-compat and less headache, I'd switch to SLF4J.
One can still use Log4J2 backend.
As for SLF4J 1.8. I don't see HC 5.0 to switch to it to maintain binary
compat.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org