axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eran Chinthaka <chinth...@opensource.lk>
Subject Re: [Axis2] Call/Stub refactoring
Date Fri, 02 Dec 2005 11:40:02 GMT


Davanum Srinivas wrote:

>Eran,
>
>I see 2 problems with the current code.
>
>#1: if i want to override stub._getClientOptions().setSoapAction().
>the generated code overwrites whatever i had set from outside. Same
>case with all others except setAction which we explicitly check. This
>is not the right behavior. We need to be able to override all the
>options set by generated code.
>  
>
Already done. Thanks !!

>#2: Suppose the generated code sets a few things in _clientOptions in
>testFoo() method, these are unintentionally carried over to testBar()
>method which is not correct. Only the things that was explicitly
>overridden by the user should be in effect in testFoo() as well as
>testBar(). Basically what will happen is the order of the calls
>becomes important. if testBar() is called first it has a different set
>of options than if it is called second (as testFoo() adds other
>things)
>  
>
hmm. Well, I think I did this intentionally.

I liked to have user set one options object and use that to invoke
multiple methods, changing whatever stuff he needs.

Basically,

Options options = new Options();
options.setTo(eprOne);
options.setTransportListenerProtocol(HTTP);
options.setUseSeparateListener(false);

Call call = new Call();
call.setClientOptions(options);

// first call to eprOne using HTTP
call.invokeBlocking(methodName, payload);

// first call to eprOne using TCP
options.setTransportListenerProtocol(TCP);
call.invokeBlocking(methodName, payload);

SO in the the second invocation, he gets whatever he has sets for the
first call.

but at the same time, if one needs to give a fresh options, he can
always set it to the Call/Stub.

I'm really sorry, if I have not understood this properly.


-- Chinthaka

>Thanks,
>dims
>
>On 12/1/05, Eran Chinthaka <chinthaka@opensource.lk> wrote:
>  
>
>> Done.
>>
>> Hope now I can proceed with the release.
>>
>> Chinthaka
>>
>>
>> Ruchith Fernando wrote:
>> Hi dims,
>>
>>Yep .. you are correct
>>
>>I was thinking about setting
>>org.apache.axis2.transport.http.HTTPConstants.CONNECTION_TIMEOUT,
>>etc
>>and was referring to setting general properties.
>>
>>We certainly have to have to fix those that u mentioned. Sorry about
>>the confusion. :-)
>>
>>Thanks,
>>Ruchith
>>
>>
>>On 12/2/05, Davanum Srinivas <davanum@gmail.com> wrote:
>>
>>
>> Ruchith,
>>
>>I don't see the timeout being set anywhere from the propertyMap in
>>Stub. Can u see it?
>>
>>thanks,
>>dims
>>
>>On 12/1/05, Ruchith Fernando <ruchith.fernando@gmail.com> wrote:
>>
>>
>> Hi Dims,
>>
>>On 12/2/05, Davanum Srinivas <davanum@gmail.com> wrote:
>>
>>
>> Eran,
>>
>>- Need a way to specify for example timeout on a generated stub.
>>Options are used inside a stub but there is no way to set it from
>>outside.
>>
>> I think this is already supported.
>>
>>Once can use o.a.axis2.client.Stub._put(String key,Object value) to
>>set the options where within the Stub they are copied over to Options
>>in the Stub.populateProperties() method.
>>
>>This behavior is used in the security test cases to set the client's
>>configurations.
>>See: org.apache.axis2.security.InteropScenarioClient
>>
>>
>>
>> - Need to remove getWsaAction/setWsaAction in Stub.java and replace it
>>with Options stuff on the Stub itself.
>>- Need to remove deprecated methods from the xsl's (setTransportInfo).
>>These are getting into the generated stubs.
>>
>>Let's please do this *BEFORE* we cut 0.93.
>>
>>Thanks,
>>dims
>>
>>--
>>Davanum Srinivas : http://wso2.com/blogs/
>>
>>
>> --
>>Ruchith
>>
>>
>> --
>>Davanum Srinivas : http://wso2.com/blogs/
>>
>>
>>
>>--
>>Ruchith
>>
>>
>>
>>    
>>
>
>
>--
>Davanum Srinivas : http://wso2.com/blogs/
>
>  
>

Mime
View raw message