hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: Collaborate implementing HTTP 2.0 support - HTTPCORE-432
Date Mon, 21 Nov 2016 23:02:13 GMT
You can also see if Travis CI and AppVeyer provide HTTP servers in their
containers.

Gary

On Mon, Nov 21, 2016 at 1:58 PM, Francisco Carriedo Scher <
fcarriedos@gmail.com> wrote:

> 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
>>> >>
>>> >>
>>> >>
>>> >
>>>
>>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>

<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
JUnit in Action, Second Edition
<https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>

<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
Spring Batch in Action
<https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

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