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 04:46:15 GMT

Don't know if migrating to Log4J2
<https://issues.apache.org/jira/browse/HTTPCORE-436> (
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 (
If you consider it correct and want me to extend it to the other modules,
just say it.

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

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.

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.


2016-09-26 20:10 GMT+02:00 Oleg Kalnichevski <olegk@apache.org>:

> On Mon, 2016-09-26 at 00:19 -0400, Francisco Carriedo Scher wrote:
> > Forked the code in pointer 1 to my own repository.
> >
> >
> > Followed the steps in pointer 2 to setup my environment and these are
> > the results by now:
> >       * mvn test OK
> >       * mvn install OK
> >       * mvn clirr:check FAILS
> >       * mvn apache-rat:check OK
> >       * mvn compile javadoc:aggregate OK
> > About the binary compatibility tests (mvn clirr:check), my impression
> > that it is probably comparing the current method signatures with
> > previous ones and most of them either changed or just didn't exist as
> > the implementation is still very young... Is this it? Is this
> > something I can safely ignore at this point?
> Hi Francisco
> Yes, you can safely ignore binary compatibility tests. They are only
> relevant for GA releases.
> > I followed the instructions in pointer 4 and I have attached a sample
> > of the output of the test execution for the module httpcore5 with
> > debug logging enabled (test.log.gz). Quick summary of what I did:
> >
> >       * Include the dependency of for Log4j in the pom.xml file of the
> >         module.
> >       * Include the commons-logging.properties file, specifying the
> >         facade for the logging implementation.
> >       * Include the log4j.properties specifying the appenders,
> >         packages and logging level for each package.
> >
> > If you find it correct, I can include the same configuration for the
> > other modules.
> >
> Most of the debug logs are still missing. Please note that the base
> package has changed from org.apache.http to org.apache.hc.core5. You
> should be getting much more output.
> > Meanwhile, I will review the pointer 3 to have a look to the new APIs
> > and provide some feedback.
> >
> The new APIs are not yet ready for a formal review though you are very
> much welcome to share your thoughts about the current state of the APIs.
> What I would like you to do though is to try to use the new HTTP/2
> transport with a popular web server with HTTP/2 support such Apache
> HTTP, Nginx or Apache Tomcat. I did some experiments with Jetty but
> could not get around to testing with other server implementations. It
> would be just awesome if you could help me with that.
> Cheers
> Oleg

View raw message