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, 21 Nov 2016 03:34:51 GMT
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
>>
>>
>>
>

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