Mailing-List: contact httpclient-users-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpClient User Discussion" <httpclient-users@hc.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4B7D9FF3.5080509@apache.org>
Date: Thu, 18 Feb 2010 21:15:47 +0100
From: Oleg Kalnichevski <olegk@apache.org>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: HttpClient User Discussion <httpclient-users@hc.apache.org>
Subject: Re: Using HttpClient (4) with 'per-connection' state
References: <27628555.post@talk.nabble.com> <27637397.post@talk.nabble.com>
In-Reply-To: <27637397.post@talk.nabble.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dave Irving wrote:
> Hi,
> 
> Thanks for your replies. I did some more digging and managed to achieve what
> I wanted without resorting to using separate HttpClient instances.
> Note that I don't think Persistent Connection State will work in this
> situation: All requests coming in to my API are considered equal and will
> 'authenticate' the same way. There isn't any conversational state (other
> than for authentication purposes), and so providing an HttpContext (for a
> single call) etc doesn't really make sense (I dont think!).
> 
> So - here's what I did (in case anyone else wants per connection cookies
> like me):
> 
> 1) Created a simple "CookieHoldingConnection" (extending
> DefaultClientConnection) which owns a BasicCookieStore
> 2) Created small DefaultClientConnectionOperator and
> ThreadSafeClientConnManager extensions so that connection requests would
> serve up one of my CookieHoldingConnections
> 3) Created a HttpRequestInterceptor implementation which does the following:
> 
> a) Digs out the connection from the HttpContext -
> context.getAttribute(ExecutionContext.HTTP_CONNECTION). This is
> unfortunately a managed connection wrapper (created by the pool) which
> doesn't have any public access to its real underlying connection, so...
> b) (The nasty bit) Dig out the real (CookieHolding) connection using
> reflection (AbstractClientConnAdapter#getWrappedConnection)
> c) Get the CookieStore from the connection and set it in the context (
> context attribute: ClientContext.COOKIE_STORE)
> 
> 4) When creating my HttpClient, simply plug in the custom connection
> manager, and add the custom interceptor (as the first inteceptor)
> 
> 
> And would you believe it.... It works like a dream.. Cookies per connection
> :)
> 
> The one thing that would perhaps make this a little cleaner would be if
> there was some way to access the custom connection cleanly so I don't have
> to resort to reflection hackery in my interceptor. 
> 
> There are a few ways this could be done: 
> 
> - Provide access to the 'real' connection in the request context (although
> this might not be a good idea - as it would make it easy for inteceptors to
> do bad things and circumvent pooling logic etc)
> - Provide a mechanism for clients to attach arbitrary state to a connection
> (and provide a delegating implementation in managed wrappers to the real
> connection etc)
> 
> e.g. HttpClientConnection#setAttribute(String name, Object value) /
> HttpClientConnection#getAttribute(String name) and a corresponding delegates
> implementations in the connection wrappers.
> 
> This would make doing this kind of thing much easier (and would obviate the
> need for custom connection implementations / operators / connection managers
> for this kind of use case).
> 
> WDYT?
> 

Please go ahead and open a change request in JIRA for this issue. Please 
  note, though, we will not be able to change the HttpClientConnection 
interface, as this would break API compatibility with previous 4.x 
releases. Most likely we will have to create a new interface that 
extends HttpClientConnection

Oleg

> If something like this were to be provided, an interceptor to achieve this
> use case would just do something like the following:
> 
> - get connection from context
> - request "cookieStore" attribute from it, and create / set it if not
> already existing
> - set the cookie store in the http context
> 
> Cheers,
> 
> Dave


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org