axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Fremantle <pzf...@gmail.com>
Subject Re: [Axis2] Stub / Call
Date Wed, 23 Nov 2005 08:33:06 GMT
Dims

I wrote a blog entry on this a while ago:

http://www.bloglines.com/blog/paulfremantle?id=15

There is also info in the attached document.

I think the solution to this is for us to make the Call injected into the
stub. So the user can get/set the underlying Call object on the stub and
then set any properties on the call object. The benefit to this is that in a
container like Spring or EJB3.0, all the properties on the call object can
be set by injection.

Paul



On 11/23/05, Davanum Srinivas <davanum@gmail.com > wrote:
>
> #1: We can't set a timeout in a generated stub.
> #2: We can set a WsaAction in stub, but no other addressing parameters
> #3: Any _put of a key/value on a stub puts it in a property bag that
> ends up in call's serviceContext
> #4: Why is call.set setting the serviceContext and not the message
> context? if the reasoning is call is for a service, then why do we
> have a setWsaAction available in call (by being defined in MEPClient)
> which is clearly per operation?
> #5: MEPClient has convenience methods for all addressing stuff AND
> methods for mih as well, but somehow the refp's are missing
> #6: The MessageContext has convenience methods for all the addressing
> stuff as well
> #7: See my hack in MEPClient line 76, it attempts to reconcile actions
> in 2 places 2 MIH's one in Stub (getMessageContext creates a
> MessageContext with a mih) and one in MEPClient.
> #8: And so on and so forth.......
>
> I feel that everyone is adding one thing and one thing there w/o any
> concern to overall architecture/usage in mind. We can't have so many
> convenience methods everywhere, we should settle down on key/value
> pairs that can be set either in call or stub (with the same effect in
> both places). We need to clean this up ASAP! All code inside client
> package should be conistent and clean and easily understandable, one
> should not have to read the code to understand what the heck is
> happening (i found the get/set in call.java was setting the service
> context by browsing code as there was no javadocs).
>
> Thanks,
> dims
>
> --
> Davanum Srinivas : http://wso2.com/blogs/
>

Mime
View raw message