Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
MIME-Version: 1.0
Reply-To: fcarriedos@gmail.com
In-Reply-To: <CACZkXPzU3rN1SXixkcmGa6uWHd8F=Puz7gcbNET7AYU805bdNA@mail.gmail.com>
References: <CAFWtOcP=7g6doH2_ORqFwJy4pF3xhSEhCHsK8zkgKV=Lw3gWvA@mail.gmail.com>
 <1474361787.3277.6.camel@apache.org> <CAFWtOcN3Rpnx4QGdX+HtYN5vEB16WTV2EOBz0Y9iifA4AMK92w@mail.gmail.com>
 <1474399445.8467.29.camel@apache.org> <CAFWtOcNigpyY8y9zbngqwgBP586pA_6eB+Cyd3=Fp0wELObqzw@mail.gmail.com>
 <1474913458.25091.19.camel@apache.org> <CAFWtOcP8ebznHDXLyzt7ioFWDHFRsRg6Yj5VsxSi80QV0kS0Aw@mail.gmail.com>
 <1477936936.24268.9.camel@apache.org> <CAFWtOcOZ3zC+kiB8KmaFF_ezAMh9kf8QhZgoGE9j5MdjXEx_iw@mail.gmail.com>
 <CAFWtOcNuMTwwMnxJbLRT3F9B8SNh0yBMh3-cPSY=fu9SWC_nrA@mail.gmail.com> <CACZkXPzU3rN1SXixkcmGa6uWHd8F=Puz7gcbNET7AYU805bdNA@mail.gmail.com>
From: Francisco Carriedo Scher <fcarriedos@gmail.com>
Date: Mon, 21 Nov 2016 16:58:08 -0500
Message-ID: <CAFWtOcOFfdyqYOZFMoGy+8JGqPLSM_S0w=de69N_s4jCu9uc_w@mail.gmail.com>
Subject: Re: Collaborate implementing HTTP 2.0 support - HTTPCORE-432
To: Gary Gregory <garydgregory@gmail.com>
Cc: HttpComponents Project <dev@hc.apache.org>
Content-Type: multipart/alternative; boundary=001a1135de447cb9a30541d6c149
archived-at: Mon, 21 Nov 2016 21:59:00 -0000

--001a1135de447cb9a30541d6c149
Content-Type: text/plain; charset=UTF-8

I will have a look to it to get some insight and consider pros/cons.

As I see it, automating tests against the most popular web servers would be
something nice if there is a relatively clean way of doing it.

2016-11-21 13:17 GMT-05:00 Gary Gregory <garydgregory@gmail.com>:

> The only way to do that is to embed a server in the test or have the test
> manage the life cycle of the external server. I've done that with Commons
> VFS tests, so it's doable.
>
> Gary
>
> On Nov 20, 2016 7:35 PM, "Francisco Carriedo Scher" <fcarriedos@gmail.com>
> wrote:
>
>> After having a look to the source code and the RFC, I would like to
>> clarify
>> a couple of things about the testing against popular web-servers.
>>
>> My first idea was to see if I could take some unit tests making requests
>> to
>> test servers as basis and generating new test classes pointing them
>> instead
>> to real running web-servers. However, after seeing the unit tests, my
>> impression is that perhaps this might not be the best approach or at least
>> complete/realistic enough.
>>
>> The intention of this testing is to test the library from a client
>> perspective (as a client of the library I mean) in more real-world
>> scenarios, not necessarily adding additional unit tests to the existing
>> ones, right?
>>
>> Aside, should an issue in Jira be open for this in order to log and
>> document versions and keep the worklog?
>>
>> Thanks,
>>
>> Francisco
>>
>>
>> 2016-10-31 19:12 GMT+01:00 Francisco Carriedo Scher <fcarriedos@gmail.com
>> >:
>>
>> > 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/46ba8b0c408cf
>> >> b67d0ed6395c675b8bd2f6fa131). 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
>> >>
>> >>
>> >>
>> >
>>
>

--001a1135de447cb9a30541d6c149--