You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Francisco Carriedo Scher <fc...@gmail.com> on 2016/10/31 04:46:15 UTC
Re: Collaborate implementing HTTP 2.0 support - HTTPCORE-432
Hello,
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 (
https://github.com/fcarriedos/httpcore/commit/46ba8b0c408cfb67d0ed6395c675b8bd2f6fa131).
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.
Thanks!
2016-09-26 20:10 GMT+02:00 Oleg Kalnichevski <ol...@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
>
>
>
>
Re: Collaborate implementing HTTP 2.0 support - HTTPCORE-432
Posted by Julian Sedding <js...@apache.org>.
It may be worthwhile to check out WireMock[0]. It allows setting up a
lightweight mock server designed for unit testing.
Regards
Julian
[0] http://wiremock.org
On Tuesday, November 22, 2016, Gary Gregory <garydgregory@gmail.com
<javascript:_e(%7B%7D,'cvml','garydgregory@gmail.com');>> wrote:
> 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 <ga...@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 <ol...@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&link
> Code=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&link
> Code=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&link
> Code=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Bli
> nk_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
>
Re: Collaborate implementing HTTP 2.0 support - HTTPCORE-432
Posted by Gary Gregory <ga...@gmail.com>.
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 <ga...@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" <fc...@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 <ol...@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
Re: Collaborate implementing HTTP 2.0 support - HTTPCORE-432
Posted by Francisco Carriedo Scher <fc...@gmail.com>.
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 <ga...@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" <fc...@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 <ol...@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
>> >>
>> >>
>> >>
>> >
>>
>
Re: Collaborate implementing HTTP 2.0 support - HTTPCORE-432
Posted by Gary Gregory <ga...@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" <fc...@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 <ol...@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
> >>
> >>
> >>
> >
>
Re: Collaborate implementing HTTP 2.0 support - HTTPCORE-432
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Mon, 2016-11-21 at 04:34 +0100, Francisco Carriedo Scher 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?
>
Correct. There is no point building test cases that depend on an
external web server.
> Aside, should an issue in Jira be open for this in order to log and
> document versions and keep the worklog?
>
You are welcome to use project wiki to document your findings / track
progress of your work [1] and raise JIRA tickets for specific detects
that you find [2]
Oleg
[1] https://wiki.apache.org/HttpComponents/
[2] https://issues.apache.org/jira/browse/HTTPCORE
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Collaborate implementing HTTP 2.0 support - HTTPCORE-432
Posted by Francisco Carriedo Scher <fc...@gmail.com>.
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 <fc...@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 <ol...@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
>>
>>
>>
>
Re: Collaborate implementing HTTP 2.0 support - HTTPCORE-432
Posted by Francisco Carriedo Scher <fc...@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 <ol...@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/
> 46ba8b0c408cfb67d0ed6395c675b8bd2f6fa131). 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
>
>
>
Re: Collaborate implementing HTTP 2.0 support - HTTPCORE-432
Posted by Oleg Kalnichevski <ol...@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/46ba8b0c408cfb67d0ed6395c675b8bd2f6fa131). 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org