Is there anyone around that would be interested in fully testing / code reviewing / etc. the code required to move to httpclient 4.x?
As much as this sounds appealing, I don't have the time and the risk / reward seems rather high since we have a working solution (I have not seen any recent bugs in the p2 bucket for proxy issues). That said, is someone is willing to take on the responsibility to make that work, I'm all for it. As for moving to another provider (e.g. jetty), if we are going with something different, I think we should still stay on the beaten path (meaning stick with httpclient). PaScaL On 2011-09-26, at 2:24 PM, Scott Lewis wrote: > As Pascal requested, here is a bug for coordinating the build and > incorporation of the connection-reuse enhancement into p2/Equinox: > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=358946 > > Further, here is the ECF enhancement for creating a provider based upon > httpclient 4.1 that Pascal referred to: > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=251740 > > WRT to the actual integration and use of new providers (i.e. httpclient 4.1, > if that's what is desired): > > ECF contributor Thomas Joiner has already implemented an ECF provider based > upon httpclient 4.1...see > https://bugs.eclipse.org/bugs/show_bug.cgi?id=251740#c17. Based upon my > understanding, httpclient 4.1 should/could solve a number of outstanding > issues with httpclient 3.1 (which the ECF filetransfer is currently based > upon)...including better/non-workaround support for NTLM v2 proxing...better > support for proxies in general...among other things. > > Realistically...I expect, however, that the new provider could have > regressions of it's own...that may take some amount of testing and > debugging...perhaps only to be detected when testing/using milestone releases > prior to 3.8. Before ECF/I start the integration, I will need commitment > from the p2/Equinox team that there will be some support for helping to test > and debug the new provider, as otherwise ECF does not currently have > resources to commit to this. The good news, of course, is that we can always > continue to use the existing providers (httpclient 3.1 or the > JRE-provider)...or fall back to them at any time if needed...via a simple > switch. > > So...before beginning the integration and testing of the work on bug > 251740...if this is important enough to the p2 team...that it be added as an > explicit plan item...and that resources be identified to assist in the > testing. > > One other question: I believe that httpclient 4.1 and the provider are both > dependent upon JRE 1.5 (I haven't looked yet at exactly where yet). > > Another possibility is to create a provider based upon Jetty Client > (some/appropriate recent version). But if this were preferred there would > have to be some resource identified to create the ECF provider (not a > difficult chore technically, but obviously takes familiarity with Jetty > client api). > > Thanks, > > Scott > > On 9/23/2011 8:38 AM, Scott Lewis wrote: >> Hi, >> >> In order to reduce time and space costs for filetransfer, ECF has recently >> added support for httpclient connection reuse >> >> https://bugs.eclipse.org/bugs/show_bug.cgi?id=297742 >> >> This change is in great need of regression testing 'in the wild' (i.e. with >> a variety of proxy environments, other network environs, etc). We have done >> all the testing that we have available to us, and I think now would be a >> good time to get it into m3. Note that there is a new system prop to >> disable the connection reuse...in case some major regression arises. >> >> Now that p2 is consuming from ECF's repos, how should this >> contribution/integration proceed? (as we don't yet have it in an ECF >> release...since it's been released since our 3.5.2 release in August). >> >> Scott >> >> >> >> >> >> _______________________________________________ >> p2-dev mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/p2-dev > > _______________________________________________ > p2-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/p2-dev _______________________________________________ p2-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/p2-dev
