Re: The complete patch for TUSCANY-1341 is available
Thanks to all who provided feedback. I plan to go with approach "3" for all the provider SPI additions. So there will be new interfaces ReferenceBindingProvider2 and ServiceBindingProvider2 that extend ReferenceBindingProvider and ServiceBindingProvider respectively, and all the new methods that I had previously addded to ReferenceBindingProvider and ServiceBindingProvider will be part of ReferenceBindingProvider2 and ServiceBindingProvider2 instead. If anyone does not think this is the right approach, please speak up now before I go further down this path. Thanks. Simon Venkata Krishnan wrote: Hi, I really like the approach mentioned under '3'. While the SPIs might undergo changes sometime, this is probably too early, especially now that we have promised for its stability from Release 0.90. Thats just about my opinion. Thanks - Venkat On 7/2/07, Simon Nash <[EMAIL PROTECTED]> wrote: I'd like to get some other views on this before I spend a lot of time reworking this patch. Please see my comments inline below. Simon ant elder wrote: > On 7/2/07, Simon Nash <[EMAIL PROTECTED]> wrote: > >> >> I am reconsidering the changes made in stage 2 of this patch, which >> added two new methods to the Binding SPI interface. >> >> I made these changes for the reasons stated in >> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19305.html >> and >> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19308.html >> These methods allow bindings to be marked as either callback or >> forward bindings. This allows callback binding semantics to be >> supported correctly with relatively little change to the core runtime. >> >> Unfortunately these is a flip side to these benefits. Adding these >> methods changes the current published stable Binding SPI, and >> (probably worse) introduces "pollution" of the Binding SPI to carry >> information that is there for the convenience of the core runtime, >> rather than an intrinsic part of the binding semantics. >> >> The alternative is to keep the Binding SPI as it was, and make more >> extensive changes in the core runtime to use the more correct version >> of the model as proposed in >> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19305.html >> >> I will look at the impact to the core runtime of the alternative >> approach that keeps the Binding SPI unchanged and I will post my >> findings back to this list. >> >> This discussion only affects the Binding SPI changes in stage 2 of >> the patch. It does not affect the provider SPI changes in stage 1 >> of the patch. >> >> I'd be interested in any comments on the above or on any other aspects >> of this patch. > > > > It sounds good the binding SPI can remain unchanged, it also sounded like > from the other thread that it should be possible to avoid some of the other > SPI changes in "stage 1" as well which would be good. > I'm getting on quite well with reworking the code that currently depends on the changes to the binding SPI. There's one slightly ugly area, but I think I'll be able to get around it without too much hackery. The provider SPI changes can't be avoided, though they can be deferred. In the short term this may seem attractive because it gets something working with less new code. However, the total amount of work will be greater since my patch already contains all the necessary collateral changes for code that's impacted by the provider SPI changes. I would have to do significant rework on the patch to remove these for now, then repeat much of this work to recreate a smilar set of collateral changes when we finally adopt these new SPIs. > How about trying to get as much as this going with as few changes to the > existing SPI as possible for now even if doing that requires some less then > perfect code in the runtime impl and axis2 binding, and then once we have > call backs and async working well with axis2 and ws-addressing and ideally > at least another extension or two then look at what the best way to change > the SPIs might be? > I think there's pretty much a straight trade-off between how many of these SPI changes are deferred and the amount of temporary workaround code that would be needed in the core to compensate for this. Let's take the provider SPI changes one by one, in approximate order of increasing difficulty for working around not having them. 1. Not including the change to remove the redundant isCallback parameter from ReferenceBindingProvider.createInvoker() doesn't cause any significant problems in the core. The core can always pass the meaningless extra parameter, and the providers can always ignore it. This does incur the collateral rework costs that I mentioned above for when we get around to cleaning this one up. 2. Not including the supportsAsyncOneWayInvocation() methods on ReferenceBindingProvider and ServiceBindingProvider presents a bit more of a challenge. One possibility is to create a new mar
Re: The complete patch for TUSCANY-1341 is available
Hi, I really like the approach mentioned under '3'. While the SPIs might undergo changes sometime, this is probably too early, especially now that we have promised for its stability from Release 0.90. Thats just about my opinion. Thanks - Venkat On 7/2/07, Simon Nash <[EMAIL PROTECTED]> wrote: I'd like to get some other views on this before I spend a lot of time reworking this patch. Please see my comments inline below. Simon ant elder wrote: > On 7/2/07, Simon Nash <[EMAIL PROTECTED]> wrote: > >> >> I am reconsidering the changes made in stage 2 of this patch, which >> added two new methods to the Binding SPI interface. >> >> I made these changes for the reasons stated in >> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19305.html >> and >> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19308.html >> These methods allow bindings to be marked as either callback or >> forward bindings. This allows callback binding semantics to be >> supported correctly with relatively little change to the core runtime. >> >> Unfortunately these is a flip side to these benefits. Adding these >> methods changes the current published stable Binding SPI, and >> (probably worse) introduces "pollution" of the Binding SPI to carry >> information that is there for the convenience of the core runtime, >> rather than an intrinsic part of the binding semantics. >> >> The alternative is to keep the Binding SPI as it was, and make more >> extensive changes in the core runtime to use the more correct version >> of the model as proposed in >> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19305.html >> >> I will look at the impact to the core runtime of the alternative >> approach that keeps the Binding SPI unchanged and I will post my >> findings back to this list. >> >> This discussion only affects the Binding SPI changes in stage 2 of >> the patch. It does not affect the provider SPI changes in stage 1 >> of the patch. >> >> I'd be interested in any comments on the above or on any other aspects >> of this patch. > > > > It sounds good the binding SPI can remain unchanged, it also sounded like > from the other thread that it should be possible to avoid some of the other > SPI changes in "stage 1" as well which would be good. > I'm getting on quite well with reworking the code that currently depends on the changes to the binding SPI. There's one slightly ugly area, but I think I'll be able to get around it without too much hackery. The provider SPI changes can't be avoided, though they can be deferred. In the short term this may seem attractive because it gets something working with less new code. However, the total amount of work will be greater since my patch already contains all the necessary collateral changes for code that's impacted by the provider SPI changes. I would have to do significant rework on the patch to remove these for now, then repeat much of this work to recreate a smilar set of collateral changes when we finally adopt these new SPIs. > How about trying to get as much as this going with as few changes to the > existing SPI as possible for now even if doing that requires some less then > perfect code in the runtime impl and axis2 binding, and then once we have > call backs and async working well with axis2 and ws-addressing and ideally > at least another extension or two then look at what the best way to change > the SPIs might be? > I think there's pretty much a straight trade-off between how many of these SPI changes are deferred and the amount of temporary workaround code that would be needed in the core to compensate for this. Let's take the provider SPI changes one by one, in approximate order of increasing difficulty for working around not having them. 1. Not including the change to remove the redundant isCallback parameter from ReferenceBindingProvider.createInvoker() doesn't cause any significant problems in the core. The core can always pass the meaningless extra parameter, and the providers can always ignore it. This does incur the collateral rework costs that I mentioned above for when we get around to cleaning this one up. 2. Not including the supportsAsyncOneWayInvocation() methods on ReferenceBindingProvider and ServiceBindingProvider presents a bit more of a challenge. One possibility is to create a new marker interface that can be implemented by providers that support asynchronous one-way invocation. The core could test for this marker interface and omit the thread switch if the provider implements it. I'm not really convinced that this is cleaner (it's probably a bit more tricky to explain than just having methods for this as we do everywhere else in the SPI), but it would get around the need for a breaking SPI change now. What do people think about this approach? 3. Not including the createCallbackInvoker() method on ServiceBindingProvider. seems at first sight to make it im
Re: The complete patch for TUSCANY-1341 is available
Folks, I tend to favour this more conservative approach. There may be a problem longer term in explaining the interfaces to writers of new binding types and implementation types, but the mess caused to existing implementation types and existing binding types by breaking changes in the SPI is not worth it, based on my experiences. My 2 cents, Mike. ant elder wrote: On 7/2/07, Simon Nash <[EMAIL PROTECTED]> wrote: 1. Not including the change to remove the redundant isCallback parameter from ReferenceBindingProvider.createInvoker() doesn't cause any significant problems in the core. The core can always pass the meaningless extra parameter, and the providers can always ignore it. This does incur the collateral rework costs that I mentioned above for when we get around to cleaning this one up. +1, this sounds a good approach to me 2. Not including the supportsAsyncOneWayInvocation() methods on ReferenceBindingProvider and ServiceBindingProvider presents a bit more of a challenge. One possibility is to create a new marker interface that can be implemented by providers that support asynchronous one-way invocation. The core could test for this marker interface and omit the thread switch if the provider implements it. I'm not really convinced that this is cleaner (it's probably a bit more tricky to explain than just having methods for this as we do everywhere else in the SPI), but it would get around the need for a breaking SPI change now. What do people think about this approach? +1, I like it a lot 3. Not including the createCallbackInvoker() method on ServiceBindingProvider. seems at first sight to make it impossible for callbacks to work. But there is (as always with software) another way. We could introduce a new interface ServiceBindingCallbackProvider that extends ServiceBindingProvider and adds the createCallbackInvoker() method. Providers that support callbacks would implement this interface, and providers that don't support callbacks could continue to implement ServiceBindingProvider. Again, this seems slightly tricky but it would work and it wouldn't need a breaking SPI change. +1 again Now I'll circle back to 1 again. The proposal for 3 has inspired me to imagine a new interface that just contains the new method signature for createInvoker(). New providers can implement this interface and the new signature, and old providers can continue with the old signature, with the core being smart enough to understand both forms and call the signature that is available. Another +1 My opinion is that the long term solution is likely to be the one I have currently implemented, so the work to change other affected code will need to be done anyway at some point. I also agree the end result is likely to be similar but IMHO the benefits of keeping things separate and stable for the time being far out way the extra work of at some point cleaning up all the SPIs (which we're going to have to do anyway). ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The complete patch for TUSCANY-1341 is available
On 7/2/07, Simon Nash <[EMAIL PROTECTED]> wrote: 1. Not including the change to remove the redundant isCallback parameter from ReferenceBindingProvider.createInvoker() doesn't cause any significant problems in the core. The core can always pass the meaningless extra parameter, and the providers can always ignore it. This does incur the collateral rework costs that I mentioned above for when we get around to cleaning this one up. +1, this sounds a good approach to me 2. Not including the supportsAsyncOneWayInvocation() methods on ReferenceBindingProvider and ServiceBindingProvider presents a bit more of a challenge. One possibility is to create a new marker interface that can be implemented by providers that support asynchronous one-way invocation. The core could test for this marker interface and omit the thread switch if the provider implements it. I'm not really convinced that this is cleaner (it's probably a bit more tricky to explain than just having methods for this as we do everywhere else in the SPI), but it would get around the need for a breaking SPI change now. What do people think about this approach? +1, I like it a lot 3. Not including the createCallbackInvoker() method on ServiceBindingProvider. seems at first sight to make it impossible for callbacks to work. But there is (as always with software) another way. We could introduce a new interface ServiceBindingCallbackProvider that extends ServiceBindingProvider and adds the createCallbackInvoker() method. Providers that support callbacks would implement this interface, and providers that don't support callbacks could continue to implement ServiceBindingProvider. Again, this seems slightly tricky but it would work and it wouldn't need a breaking SPI change. +1 again Now I'll circle back to 1 again. The proposal for 3 has inspired me to imagine a new interface that just contains the new method signature for createInvoker(). New providers can implement this interface and the new signature, and old providers can continue with the old signature, with the core being smart enough to understand both forms and call the signature that is available. Another +1 My opinion is that the long term solution is likely to be the one I have currently implemented, so the work to change other affected code will need to be done anyway at some point. I also agree the end result is likely to be similar but IMHO the benefits of keeping things separate and stable for the time being far out way the extra work of at some point cleaning up all the SPIs (which we're going to have to do anyway). ...ant
Re: The complete patch for TUSCANY-1341 is available
I'd like to get some other views on this before I spend a lot of time reworking this patch. Please see my comments inline below. Simon ant elder wrote: On 7/2/07, Simon Nash <[EMAIL PROTECTED]> wrote: I am reconsidering the changes made in stage 2 of this patch, which added two new methods to the Binding SPI interface. I made these changes for the reasons stated in http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19305.html and http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19308.html These methods allow bindings to be marked as either callback or forward bindings. This allows callback binding semantics to be supported correctly with relatively little change to the core runtime. Unfortunately these is a flip side to these benefits. Adding these methods changes the current published stable Binding SPI, and (probably worse) introduces "pollution" of the Binding SPI to carry information that is there for the convenience of the core runtime, rather than an intrinsic part of the binding semantics. The alternative is to keep the Binding SPI as it was, and make more extensive changes in the core runtime to use the more correct version of the model as proposed in http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19305.html I will look at the impact to the core runtime of the alternative approach that keeps the Binding SPI unchanged and I will post my findings back to this list. This discussion only affects the Binding SPI changes in stage 2 of the patch. It does not affect the provider SPI changes in stage 1 of the patch. I'd be interested in any comments on the above or on any other aspects of this patch. It sounds good the binding SPI can remain unchanged, it also sounded like from the other thread that it should be possible to avoid some of the other SPI changes in "stage 1" as well which would be good. I'm getting on quite well with reworking the code that currently depends on the changes to the binding SPI. There's one slightly ugly area, but I think I'll be able to get around it without too much hackery. The provider SPI changes can't be avoided, though they can be deferred. In the short term this may seem attractive because it gets something working with less new code. However, the total amount of work will be greater since my patch already contains all the necessary collateral changes for code that's impacted by the provider SPI changes. I would have to do significant rework on the patch to remove these for now, then repeat much of this work to recreate a smilar set of collateral changes when we finally adopt these new SPIs. How about trying to get as much as this going with as few changes to the existing SPI as possible for now even if doing that requires some less then perfect code in the runtime impl and axis2 binding, and then once we have call backs and async working well with axis2 and ws-addressing and ideally at least another extension or two then look at what the best way to change the SPIs might be? I think there's pretty much a straight trade-off between how many of these SPI changes are deferred and the amount of temporary workaround code that would be needed in the core to compensate for this. Let's take the provider SPI changes one by one, in approximate order of increasing difficulty for working around not having them. 1. Not including the change to remove the redundant isCallback parameter from ReferenceBindingProvider.createInvoker() doesn't cause any significant problems in the core. The core can always pass the meaningless extra parameter, and the providers can always ignore it. This does incur the collateral rework costs that I mentioned above for when we get around to cleaning this one up. 2. Not including the supportsAsyncOneWayInvocation() methods on ReferenceBindingProvider and ServiceBindingProvider presents a bit more of a challenge. One possibility is to create a new marker interface that can be implemented by providers that support asynchronous one-way invocation. The core could test for this marker interface and omit the thread switch if the provider implements it. I'm not really convinced that this is cleaner (it's probably a bit more tricky to explain than just having methods for this as we do everywhere else in the SPI), but it would get around the need for a breaking SPI change now. What do people think about this approach? 3. Not including the createCallbackInvoker() method on ServiceBindingProvider. seems at first sight to make it impossible for callbacks to work. But there is (as always with software) another way. We could introduce a new interface ServiceBindingCallbackProvider that extends ServiceBindingProvider and adds the createCallbackInvoker() method. Providers that support callbacks would implement this interface, and providers that don't support callbacks could continue to implement ServiceBindingProvider. Again, this seems sl
Re: The complete patch for TUSCANY-1341 is available
On 7/2/07, Simon Nash <[EMAIL PROTECTED]> wrote: I am reconsidering the changes made in stage 2 of this patch, which added two new methods to the Binding SPI interface. I made these changes for the reasons stated in http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19305.html and http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19308.html These methods allow bindings to be marked as either callback or forward bindings. This allows callback binding semantics to be supported correctly with relatively little change to the core runtime. Unfortunately these is a flip side to these benefits. Adding these methods changes the current published stable Binding SPI, and (probably worse) introduces "pollution" of the Binding SPI to carry information that is there for the convenience of the core runtime, rather than an intrinsic part of the binding semantics. The alternative is to keep the Binding SPI as it was, and make more extensive changes in the core runtime to use the more correct version of the model as proposed in http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19305.html I will look at the impact to the core runtime of the alternative approach that keeps the Binding SPI unchanged and I will post my findings back to this list. This discussion only affects the Binding SPI changes in stage 2 of the patch. It does not affect the provider SPI changes in stage 1 of the patch. I'd be interested in any comments on the above or on any other aspects of this patch. It sounds good the binding SPI can remain unchanged, it also sounded like from the other thread that it should be possible to avoid some of the other SPI changes in "stage 1" as well which would be good. How about trying to get as much as this going with as few changes to the existing SPI as possible for now even if doing that requires some less then perfect code in the runtime impl and axis2 binding, and then once we have call backs and async working well with axis2 and ws-addressing and ideally at least another extension or two then look at what the best way to change the SPIs might be? There's a few other unrelated changes we probably need to do in the SPI as well, maybe we can save them all up and then have a single separate release specially for all these breaking changes and deprecate things so its really clear how/what/why things changed. ...ant
Re: The complete patch for TUSCANY-1341 is available
I am reconsidering the changes made in stage 2 of this patch, which added two new methods to the Binding SPI interface. I made these changes for the reasons stated in http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19305.html and http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19308.html These methods allow bindings to be marked as either callback or forward bindings. This allows callback binding semantics to be supported correctly with relatively little change to the core runtime. Unfortunately these is a flip side to these benefits. Adding these methods changes the current published stable Binding SPI, and (probably worse) introduces "pollution" of the Binding SPI to carry information that is there for the convenience of the core runtime, rather than an intrinsic part of the binding semantics. The alternative is to keep the Binding SPI as it was, and make more extensive changes in the core runtime to use the more correct version of the model as proposed in http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19305.html I will look at the impact to the core runtime of the alternative approach that keeps the Binding SPI unchanged and I will post my findings back to this list. This discussion only affects the Binding SPI changes in stage 2 of the patch. It does not affect the provider SPI changes in stage 1 of the patch. I'd be interested in any comments on the above or on any other aspects of this patch. Simon Simon Nash wrote: Please review and apply the patch for TUSCANY-1341 which I have attached to the JIRA in 7 parts as follows. Stages 1, 2 and 3 contain new SPIs and bug fixes that are needed to support callbacks across bindings. They do not have cross- dependencies and can be applied in any order. Stage 4 depends on the previous stages and provides core runtime enablement for the new callback functionality. Stage 5 depends on the previous stages and provides callback support in the Web Service binding. Stage 6 provides a new sample to illustrate this capability. Stage 7 makes this new sample part of the build. See my comments in the JIRA for the above patches for more details of what they contain. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
The complete patch for TUSCANY-1341 is available
Please review and apply the patch for TUSCANY-1341 which I have attached to the JIRA in 7 parts as follows. Stages 1, 2 and 3 contain new SPIs and bug fixes that are needed to support callbacks across bindings. They do not have cross- dependencies and can be applied in any order. Stage 4 depends on the previous stages and provides core runtime enablement for the new callback functionality. Stage 5 depends on the previous stages and provides callback support in the Web Service binding. Stage 6 provides a new sample to illustrate this capability. Stage 7 makes this new sample part of the build. See my comments in the JIRA for the above patches for more details of what they contain. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
