[
https://issues.apache.org/jira/browse/AXIS2-4288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12694955#action_12694955
]
Dobri Kitipov commented on AXIS2-4288:
--------------------------------------
Hi Amila,
1) Yes it is HttpConstants. I am sorry for the confusion. We use some wrappers
overhere, so I just copied a sample which is not pure Axis2 one. Here is the
pure Axis2 one:
client.getOptions().setProperty(HttpConstants.CACHED_HTTP_STATE, new
HttpState());
2) Yes, right. If there is no httpState (it is null) then the one associated
with the HttpClient will be used. So at end the code will behave as it did
before the change. Thus it is backward compatible.
3) Yes, right. This is more simpler and thus more reliable way to keep the
HttpState. I originally thought about this, but finally decided that it is more
natural to keep the HttpState into the ServiceContext. I saw that cookies are
kept into the ServiceContext (see
AbstractHTTPSender.obtainHTTPHeaderInformation) and since they are part of the
HttpState it seemed to me that this is the prefered place.
Please, provide me with your comments (e.g. cons and pros) about keeping the
HttpState into ServiceContext.
Anyway, I will update the patches and the HttpState will be kept into the
MessageContext.
Thanks,
Dobri
> 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 httpclient-us...@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-us...@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.
