Sticking with 3.x is fine with me. We are seeing good performance from this in production for proxying, it does a very good job maintaining the connection pool. Now I just have to convince all our partners to support keep-alive.
FYI - There is a maven repo for snapshot builds http://people.apache.org/repo/m2-snapshot-repository/org/apache/httpcomponen ts/httpclient/ On 5/6/08 2:30 PM, "Kevin Brown" <[EMAIL PROTECTED]> wrote: > On Tue, May 6, 2008 at 2:07 PM, Brian Eaton <[EMAIL PROTECTED]> wrote: > >> There doesn't seem to be a maven repository for httpclient 4.0 yet. I >> can upgrade OAuth, but if repo.maven.org doesn't have 4.0 yet I wonder >> whether it is ready for prime-time. > > > Even though I really like the httpclient 4 design (I'd actually remove a > large portion of our code and use that stuff in place), it's probably not > viable to use it due to versioning conflicts. We should revisit this > sometime after the first stable release, though. For now I am going to move > us to using HttpClient by default, just using the 3.x version until 4.x > becomes viable. > > >> >> On Sun, May 4, 2008 at 2:09 AM, Kevin Brown <[EMAIL PROTECTED]> wrote: >>> Hey Paul, >>> >>> I can't seem to get 4.0 working at all because it conflicts with the >>> httpclient-3.1 dependency in OAuth (which is a part of a sub package >> that we >>> don't even use...). Have you figured out a way around this? >>> >>> >>> >>> On Mon, Apr 28, 2008 at 4:04 AM, Paul Lindner <[EMAIL PROTECTED]> wrote: >>> >>>> On Mon, Apr 28, 2008 at 02:59:57AM -0700, Kevin Brown wrote: >>>>> >>>>> >>>>> I had a JIRA issue open to migrate to HttpClient instead of using >>>>> URLConnection, but I was still leaning towards a wrapper interface >> of >>>> some >>>>> sort for various reasons, the main one being that the older >> HttpClient >>>>> interface was difficult to extend. I haven't looked at the 4.0 >> interface >>>>> yet, but I trust your judgment. >>>> >>>> I've attached our implementation. (Please note that this was coded >>>> under duress, so it could stand to be cleaned up a bit..)) >>>> >>>> It appears that oen could extend HttpClient with their concept of >>>> built-in interceptors to implement most of the features we want. >>>> Here's a sample that injects the Accept-Encoding header into outbound >>>> requests: >>>> >>>> // Add hooks for gzip/deflate >>>> client.addRequestInterceptor(new HttpRequestInterceptor() { >>>> public void process( >>>> final HttpRequest request, >>>> final HttpContext context) throws HttpException, >>>> IOException { >>>> if (!request.containsHeader("Accept-Encoding")) { >>>> request.addHeader("Accept-Encoding", >> "gzip,deflate"); >>>> } >>>> } >>>> }); >>>> >>>> >>>>> One of the big things I think we should do is drop the tight >> coupling of >>>> the >>>>> auth modes to the http retrieval, and instead have something >> dedicated >>>> to >>>>> dealing with various types of auth. Packing oauth and request >> signing >>>> into >>>>> the fetchers was an interesting experiment, but the end results are >>>> barely >>>>> better than the previous revisions where stuff was crammed into the >>>> proxy. >>>>> Now that there are multiple places where auth needs to be done, >> it's >>>> even >>>>> uglier to deal with. I think a bunch of us had good ideas here, but >> they >>>>> didn't really mesh well together and the end result is pretty poor. >>>> >>>> Okay. Sounds like it might be possible to factor out the >>>> auth/signing code and then write adapters (like you see above) to >>>> loosely integrate the pieces. >>>> >>>>> There's no time like the present to fix this stuff up, I suppose, >> since >>>>> changes in the last few weeks, and those coming in the next few are >>>> dramatic >>>>> enough that anyone doing heavy integration work is already in for a >>>> rough >>>>> patch. >>>> >>>> Ooof. Anything we can do to make this easier will be welcome. >>>> >>>> >>>> -- >>>> Paul Lindner >>>> hi5 Architect >>>> [EMAIL PROTECTED] >>>> >>> >>
