Ok, I lied. I actually went for the low hanging fruit and took care of 2. I posted patch 'Simpl...7.patch' for TUSCANY-642.
On 10/31/06, Ignacio Silva-Lepe <[EMAIL PROTECTED]> wrote:
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
