axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Amila Chinthaka Suriarachchi (JIRA)" <>
Subject [jira] Commented: (AXIS2-4288) Support HttpState object association with a client and use it when invoking httpClient.executeMethod(...)
Date Thu, 02 Apr 2009 05:22:13 GMT


Amila Chinthaka Suriarachchi commented on AXIS2-4288:

client.getOptions().setProperty(WSClientConstants.CACHED_HTTP_STATE, new HttpState());

is this WSClientConstants or HttpConstants?

httpClient.executeMethod(config, method, httpState);
if the httpState is null then does that get the http stat associated with httpClient?

Why do you need to keep the http state in the service Context? when you set it as an option

of the service client it automatically copies to all the MessageContexts.

> Support HttpState object association with a client and use it when invoking httpClient.executeMethod(...)
> ---------------------------------------------------------------------------------------------------------
>                 Key: AXIS2-4288
>                 URL:
>             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,
> 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 [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]
> [2]

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

View raw message