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? 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 -- View this message in context: http://old.nabble.com/Using-HttpClient-%284%29-with-%27per-connection%27-state-tp27628555p27637397.html Sent from the HttpClient-User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
