[
https://issues.apache.org/jira/browse/AXIS2-4288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12695969#action_12695969
]
Amila Chinthaka Suriarachchi commented on AXIS2-4288:
-----------------------------------------------------
there is no any problem with keeping state in the ServiceContext. What I
thought was if it is enough to keep in messageContext it is better to do in
that way.
I am ok to commit this patch.
this patch only make any effect if the user set this property.
client.getOptions().setProperty(HttpConstants.CACHED_HTTP_STATE, new
HttpState());
so it does not change the default behaviour.
> 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.patch,
> HTTPConstants_AXIS2-4288_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 [email protected]
> [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/[email protected]/msg45787.html
> [2] http://www.mail-archive.com/[email protected]/msg01944.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
