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 <[email protected]>: > 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" <[email protected]> > 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 <[email protected] >> >: >> >> > 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 <[email protected]>: >> > >> >> 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 >> >> >> >> >> >> >> > >> >
