Simon, You seem to be saying there's an equivalence between binding.sca @uri and reference target in terms of promotion behavior. I cannot find anything in the spec that supports that.
Here is the description of nonOverridable: 876 nonOverridable : boolean (0..1) - a boolean value, "false" by default, which indicates whether this 877 component reference can have its targets overridden by a composite reference which promotes the 878 component reference. 879 If @nonOverridable==false, if any target(s) are configured onto the composite references which 880 promote the component reference, then those targets replace all the targets explicitly declared on the 881 component reference for any value of @multiplicity on the component reference. If no targets are 882 defined on any of the composite references which promote the component reference, then any 883 targets explicitly declared on the component reference are used. This means in effect that any targets declared on the component reference act as default targets for that reference. This description explicitly talks about reference targets. There is nothing here that mentions bindings. This description also doesn't explain how nonOverridable applies to higher-level composites that reuse this composite. It only describes the interaction between the composite reference and the component reference within the composite itself. If targets are specified on both an 'outer' component reference and its promoted 'inner' component reference, what is supposed to happen? Is it dependent on the setting of nonOverridable? I can't find anything that addresses this. Here is the description of how bindings are overridden. 900 binding : Binding (0..n) - A reference element has zero or more binding elements as children.If no 901 binding elements are specified for the reference, then the bindings specified for the equivalent 902 reference in the componentType of the implementation MUST be used. If binding elements are 903 specified for the reference, then those bindings MUST be used and they override any bindings 904 specified for the equivalent reference in the componentType of the implementation. [ASM50012] There is nothing in those lines talking about nonOverridable having any effect on binding override. So where is this equivalence between binding uri and reference target stated? Does it apply just to binding.sca or to all bindings? On Fri, Aug 5, 2011 at 7:00 AM, Simon Laws <simonsl...@googlemail.com>wrote: > On Thu, Aug 4, 2011 at 4:44 PM, Greg Dritschler > <greg.dritsch...@gmail.com> wrote: > > Thanks Mike. > > 5018 is close to my test. In 5018, the inner composite (TestComposite10) > > has the binding on the COMPOSITE reference. In my test, the inner > composite > > has the binding on the COMPONENT reference, and the COMPOSITE reference > > promotes that reference without specifying any bindings (so it inherits > the > > one from my component reference). > > I think the end result should the same? The outer component reference > > should be able to override the binding in either case? > > > > On Thu, Aug 4, 2011 at 10:36 AM, Mike Edwards > > <mike.edwards.inglen...@gmail.com> wrote: > >> > >> On 04/08/2011 14:27, Greg Dritschler wrote: > >>> > >>> >From the assembly spec on component references: > >>> > >>> 900 binding : Binding (0..n) - A reference element has zero or more > >>> binding elements as children. If no > >>> 901 binding elements are specified for the reference, then the bindings > >>> specified for the equivalent > >>> 902 reference in the componentType of the implementation MUST be used. > If > >>> binding elements are > >>> 903 specified for the reference, then those bindings MUST be used and > >>> they override any bindings > >>> 904 specified for the equivalent reference in the componentType of the > >>> implementation. [ASM50012] > >>> > >>> If this doesn't hold true, then there's no reason to be able to promote > >>> references, because there's > >>> no possibility to reconfigure them. > >>> > >>> I can't find a compliance test for this. > >>> > >> Greg, > >> > >> Not sure what "this" applies to here. > >> > >> However, [ASM50012] relates to test assertions TA 5017 and TA 5018 which > >> in turn are implemented by testcases 5017 and 5018: > >> > >> 5017: > >> "Tests that where a <reference/> of a <component/> has no <binding/> > child > >> element, but the corresponding <reference/> element in the componentType > >> does have a binding child element, the <binding/> from the componentType > is > >> used for the reference" > >> > >> > >> 5018: > >> "Tests that where a <reference/> of a <component/> has a <binding/> > child > >> element and the corresponding <reference/> element in the componentType > has > >> a binding child element, the <binding/> from the <reference/> is used > for > >> the reference" > >> > >> If it's the promotion aspect you're concerned about, then there are > other > >> testcases that deal with that, eg 5023. > >> > >> > >> Yours, Mike. > >> > >> > > > > > > Greg > > I had a chat with Mike off-line about this as there seems to be > multiple angles to this problem. The conclusion is that I think we are > not processing @nonOverribeable correctly in the code as it stands. > This is what I think should happen... > > ==================================================== > > INPUT MODEL > > CompositeA > ComponentA > implementation.composite > CompositeB > ReferenceBpromoted > @mulitplicity="1..1" > @promote="ReferenceB" > ComponentB > ReferenceB > @mulitplicity="1..1" - the default > @nonOverrideable="false" - the default > @target="targetB" > ReferenceB > @mulitplicity="1..1" - the default > @target="targetA" > > RUNTIME MODEL > > ComponentRuntime > ReferenceRuntime > @target="targetA" > > ==================================================== > > INPUT MODEL > > CompositeA > ComponentA > implementation.composite > CompositeB > ReferenceBpromoted > @mulitplicity="1..1" > @promote="ReferenceB" > ComponentB > ReferenceB > @mulitplicity="1..1" - the default > @nonOverrideable="true" > @target="targetB" > ReferenceB > @mulitplicity="1..1" - the default > @target="targetA" > > RUNTIME MODEL > > ComponentRuntime > ReferenceRuntime > @target="targetA" > @target="targetB" > > Which results in a validation error as this conflicts with the > reference multiplicity > > ==================================================== > > INPUT MODEL > > CompositeA > ComponentA > implementation.composite > CompositeB > ReferenceBpromoted > @mulitplicity="1..1" > @promote="ReferenceB" > ComponentB > ReferenceB > @mulitplicity="1..1" - the default > @nonOverrideable="false" - the default > binding.sca > @uri="targetB" > ReferenceB > @mulitplicity="1..1" - the default > binding.sca > @uri="targetA" > > > RUNTIME MODEL > > ComponentRuntime > ReferenceRuntime > binding.sca > @uri="targetA" > > ==================================================== > > INPUT MODEL > > CompositeA > ComponentA > implementation.composite > CompositeB > ReferenceBpromoted > @mulitplicity="1..1" > @promote="ReferenceB" > ComponentB > ReferenceB > @mulitplicity="1..1" - the default > @nonOverrideable="true" > binding.sca > @uri="targetB" > ReferenceB > @mulitplicity="1..1" - the default > binding.sca > @uri="targetA" > > RUNTIME MODEL > > ComponentRuntime > ReferenceRuntime > binding.sca > @uri="targetA" > binding.sca > @uri="targetB" > > Which results in a validation error as this conflicts with the > reference multiplicity > > ==================================================== > > Apologies for the somewhat compressed format. Assuming you agree with > this can you raise JIRA for the problem. > > Regards > > Simon > > -- > Apache Tuscany committer: tuscany.apache.org > Co-author of a book about Tuscany and SCA: tuscanyinaction.com >
