[jira] Commented: (AXIS2-4288) Support HttpState object association with a client and use it when invoking httpClient.executeMethod(...)

["Dobri Kitipov (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/AXIS2-4288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715950#action_12715950 ] 

Dobri Kitipov commented on AXIS2-4288:
--------------------------------------

The documentation is committed.

> Support HttpState object association with a client and use it when invoking httpClient.executeMethod(...)
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: AXIS2-4288
>                 URL: https://issues.apache.org/jira/browse/AXIS2-4288
>             Project: Axis 2.0 (Axis2)
>          Issue Type: New Feature
>          Components: kernel, transports
>            Reporter: Dobri Kitipov
>         Attachments: AbstractHTTPSender_AXIS2-4288_1.1.patch, AbstractHTTPSender_AXIS2-4288_1.patch, HTTPConstants_AXIS2-4288_1.1.patch, HTTPConstants_AXIS2-4288_1.patch, ProxyConfiguration_AXIS2-4288_1.1.patch, ProxyConfiguration_AXIS2-4288_1.patch
>
>
> Hi all,
> I am opening a new JIRA related to the HttpState association with a given Axis client.
> The use case
> I want to point out a concrete use case I have. I want to reuse a HttpClient among different instances of a clients which are executed in different threads. Every client can make several invocations. The clients can call different Web Services (WSs) deployed at different hosts/servers. As a consequence every client may need to provide different authentication Credentials and may need to support transport sessions using Cookies.
> Both Credentials and Cookies are part of the HttpState. As a result the HttpState associated with the HttpClient that is reused cannot be reused that easily in the scenario described above. Credentials are associated with a given host, port, realm and authentication schema (defines the AuthScope object used as a key for the credentials Map part of the HttpState).
> Following is an excerpt from the AbstractHTTPSender#setAuthenticationInfo:
> creds = new UsernamePasswordCredentials(username, password);
> agent.getState().setCredentials(new AuthScope(host, port, realm), creds);
> Credentials are kept into a Map and could be identified uniquely from client to client (thread to thread), but this Map is exposed to all clients which reuse the HttpClient which is not a good idea.
> The situation with the other member of the HttpState (i.e. Cookies) is similar. When we have *different* client instances (configured to use cookies options.setManageSession(true)) calling one and the same WS's operation then the effect is that both are sharing one JSESSIONID.
> The proposal
> The proposal is based on my question posted at httpclient-users@hc.apache.org [2]
> The idea is to provide the capability to specify/associate a separate HttpState with every client and still reuse one and the same HttpClient. What you just need is to pass it as a parameter to the HttpClient#executeMethod.
> I decided that the HttpState should be kept into the ServiceContext. I did all changes needed in Axis2 kernel (in fact they are really few) and added the possibility to use a separate HttpState and invoke HttpClient#executeMethod passing it as a parameter. The changes keep the kernel backward compatible. I did and several tests and it looks good.
> Please, give me your comments. Do you like this extension? If so I can provide you with the changes and finally we can agree on committing them into the kernel. 
> I have the patches but we are using a little bit older version of axis2 .I need some time to apply the changes to the trunk version. Then I will provide them. 
> Although I am a WS committer I can not commit anything since I am still waiting my company's lawyers to check all aspects of this. 
> Thank you,
> Dobri
> [1] http://www.mail-archive.com/axis-dev@ws.apache.org/msg45787.html
> [2] http://www.mail-archive.com/httpclient-users@hc.apache.org/msg01944.html

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