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 <[email protected]> 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" <[email protected]> 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: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
