Ok, I may not be as quick with these changes this time but I can takecare of them. I probably will do 1 (and perhaps 2) in one chunk and 3 in another. Who knows, perhaps my commit rights will be ready by the time I do one or both and I won't have to post patches ...
On 10/31/06, Jim Marino <[EMAIL PROTECTED]> wrote:
On Oct 31, 2006, at 10:41 AM, Ignacio Silva-Lepe wrote: > Hi Jim, > > The changes sound reasonable, with a few comments. > > 1. Target invokers for binding.axis2, specifically on the reference > side, invoke an axis2 operation client as non-blocking, and in the > case of Axis2AsyncTargetInvoker, also sets up the callback > target invoker given to the operation client. It's possible to combine > this logic into one class but my first approach was to separate it > for clarity. Yea it may be easier for createTargetInvoker just to return multiple subtypes in cases where it makes things clearer (some implementations may combine it into one, like Java components) > > 3. Message ids are used only to indicate an invocation context on > behalf of the axis2 binding on the service side. The call paths still > manipulate it if it is present in the message but the only place where > a message id is instantiated at the moment is the in-out async > axis2 message receiver. Since a message id is seen as an object, > the receiver could just pull the message id from the axis2 message > context and use that instead of instantiating a UUID. What do you > think? > That sounds even better. Do you want to take care of these changes? Jim
