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
