On 6/30/07, Simon Nash <[EMAIL PROTECTED]> wrote:
Because my patch for supporting callbacks across the Web Service binding is quite large, I am splitting it into a series of smaller patches to make it easier to apply. The first of these patches adds some methods to ReferenceBindingProvider and ServiceBinding Provider. At present I have have placed default implementations of the new methods in all the affected places. These will be replaced by fully implemented versions later. The code to call these new methods will be added in the next stages of this multi-part patch. I have rebuilt the trunk with this patch and everything seems OK. Since the new code isn't being called yet, there should be no effect (either good or bad) at this stage. I have attached the patch to TUSCANY-1341. Here is a brief description of the new methods: ReferenceBindingProvider.createInvoker(Operation) is a replacement for the current method of the same name that also has a boolean isCallback parameter. This second parameter is no longer needed because binding callback invokers will be created using the new method ServiceBindingProvider.createCallbackInvoker(Operation) instead. The supportsAsyncOneWayInvocation() method on ReferenceBindingProvider indicates whether the provider supports non-blocking semantics for one-way forward invocations. The supportsAsyncOneWayInvocation() method on ServiceBindingProvider indicates whether the provider supports non-blocking semantics for one-way callback invocations. The ServiceBindingProvider.createCallbackInvoker(Operation) method creates a callback invoker for the binding.
Thanks, its good to be trying to keep the patches small as that does make it much easier to understand and review them. This is making breaking changes to the SPI that we've said we'll try real hard to keep stable so I'd really like it to be clear what all the changes are for: - What are the new supportsAsyncOneWayInvocation methods for? If its just an optimization so the runtime can sometimes avoid a thread switch then could we leave that optimization to be done later when there's a more complete picture on how all the async/conversational/etc stuff is working? - Similar thing with the change of the createInvoker signature, a comment says "isCallback parameter is no longer used and will be removed in next stage of callback support", could this just be left as-is for now and the isCallback parameter be cleaned up later? ...ant
