[ 
https://issues.apache.org/jira/browse/HTTPCLIENT-915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12835704#action_12835704
 ] 

Ortwin Glück commented on HTTPCLIENT-915:
-----------------------------------------

I see your point. Anyway I think it's a bit questionable design. This basically 
introduces global variables, very well comparable with thread-local variables. 
We all know where that leads if you start passing all sorts of information 
around that way. Better keep local Maps with the Connection as the (weak ref) 
key. You can better controll access to those maps individually.

> Provide a clean mechanism to attatch user define attributes to connections
> --------------------------------------------------------------------------
>
>                 Key: HTTPCLIENT-915
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-915
>             Project: HttpComponents HttpClient
>          Issue Type: New Feature
>          Components: HttpConn
>    Affects Versions: 4.0.1
>            Reporter: dave irving
>            Priority: Minor
>             Fix For: 4.1 Alpha2
>
>
> It would be nice to have a way to attach user defined attributes to a 
> connection.
> Ideally it'd be nice if such support could be added to HttpClientConnection, 
> but understandably this may not be possible due to back-compatibility issues.
> So, we could have something like HttpConnectionContext perhaps (or similar) 
> with:
> HttpConnectionContext#setAttribute(String name, Object value)
> Object HttpConnectionContext#getAttribute(String name)
> This would be made available in the HttpContext of a request (like the 
> connection is today):
> HttpConnectionContext connectionContext = (HttpConnectionContext) 
> httpContext.getAttribute(ExecutionContext.HTTP_CONNECTION_CONTEXT);
> This would make a few things much cleaner to implement than they are today: 
> The most obvious being my current use case of wanting connection isolated 
> cookies.
> Currently to achieve this goal we need to provide custom client connection + 
> connection operator + connection manager implementations. Then there is no 
> clean way to currently obtain the actual connection instance created by a 
> custom operator in the HttpContext: As it's wrapped by the connection pool 
> and #getWrappedConnection is protected - so we need to resort to reflection 
> in interceptors.
> Providing a clean mechanism for attaching user defined attributes to a 
> connection instance as described above would make such implementations far 
> far simpler.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to