hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Francisco Carriedo Scher <fcarrie...@gmail.com>
Subject Re: Collaborate implementing HTTP 2.0 support - HTTPCORE-432
Date Mon, 31 Oct 2016 18:12:23 GMT
Yes, I find moving to Log4J2 the correct choice too, so leaving Gary work
on the migration without conflict.

I will move then forward testing against popular HTTP/2 enabled servers.


2016-10-31 14:02 GMT-04:00 Oleg Kalnichevski <olegk@apache.org>:

> On Mon, 2016-10-31 at 05:46 +0100, Francisco Carriedo Scher wrote:
> > Hello,
> >
> >
> > Don't know if migrating to Log4J2
> > (https://issues.apache.org/jira/browse/HTTPCORE-436) would override
> > the task I was working in (enabling debug logging on integration
> > tests). Anyway, as I don't know how long migrating might take and the
> > work was already done for httpcore5 module I have committed it to my
> > fork
> > (https://github.com/fcarriedos/httpcore/commit/
> 46ba8b0c408cfb67d0ed6395c675b8bd2f6fa131). If you consider it correct and
> want me to extend it to the other modules, just say it.
> >
>
> Francisco
>
> This will certainly conflict with Gary's changes. I had no idea you were
> going to introduce Log4j as a dependency. What you have done looks
> perfectly fine to me but going forward we should be using Log4j2 given
> that it provides an abstract logging API with an option of using
> different logging back-ends.
>
> >
> > Question: I determined which packages to enable logging for with the
> > shell command below (output attached). To me this should find any
> > class needing to yield debug log lines. Could somebody comment on
> > this? (Correct, incorrect, suggestions?). Thanks!
> > $ httpcore/httpcore5$ reset && egrep -Ri "log" ./* | grep java | grep
> debug
>
> Looks correct to me.
>
> > DEADLOCK: when I completed this a month ago, enabling debug logging
> > resulted in a dead-lock in class "TestSyncHttp.java". This test class
> > is not present anymore and the deadlock does not appear now, but I
> > don't know if this could be another good reason to work on updating
> > the logging framework (HTTPCORE-436), as I dug a bit and looked like a
> > known issue for Log4J 1.2. I can reproduce the deadlock and provide
> > more detail if needed.
> >
>
> More reason to move to Log4j2.
>
> > Meanwhile I will have a look to testing the HTTP/2 transport with
> > popular web servers as you suggested. Please confirm if this is still
> > pending or somebody already is taking care of it.
> >
>
> I confirm. This is still by far more important than anything else.
>
> Oleg
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message