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" <[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]
