we'd have to see some proposals on how to modify the current code generation and runtime to implement that :) If we go this route, We also have another fundamental issue, same Stub instance is supposed to be usable across multiple threads. (First of all, we need to review the code and make sure that this is still true in current impl). We also need to figure out how to "inject the call" such that this premise still holds good.
thanks, dims On 11/23/05, Paul Fremantle <[EMAIL PROTECTED]> wrote: > 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 < [EMAIL PROTECTED] > 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/ > > > > > -- Davanum Srinivas : http://wso2.com/blogs/
