Thanks Mike, this helps a lot.
I think the description of nonOverridable needs to explicitly say that it
applies to all of the methods described in 4.3.1. It also needs to say that
it controls not only how targets are handled between the composite ref and
its promoted component ref, but also between the next higher component ref
and the composite ref.
Simon, I tried adding a test to pushDownEndpointReferences() to look at the
nonOverridable setting of the promoted component reference. This fixed my
1..1 tests. I haven't tried other cases yet.
for (ComponentReference leafRef : leafComponentReferences){
if (!leafRef.isNonOverridable()) {
leafRef.getEndpointReferences().clear();
}
int insertLocation = 0;
...
On Fri, Aug 5, 2011 at 11:53 AM, Mike Edwards <
mike.edwards.inglen...@gmail.com> wrote:
> Greg,
>
> I'll try to address this with some inline replies, but I get the feeling
> that maybe a conf call will be needed to interactively work on your
> concerns.
>
>
> Yours, Mike.
>
>
> On 05/08/2011 16:12, Greg Dritschler wrote:
>
>> 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.
>>
>
> There are a lot of bones to pick out of here - let me see if I can
> disentangle them.
>
> 1) This section talks about "targets" of a reference in the sense implied
> by section 4.3.1 of the specification. There are 7 ways described in there
> for specifying a target service for a reference, which includes binding
> specific stuff like binding @uri values. So it is intended to cover bindings
> as well as the other ways of specifying a target service.
>
> 2) How does nonOverridable apply to a higher level COMPONENT (not
> composite) that reuse this composite? The answer is that it does not. ie
> the setting has no effect on the configuration of the higher level component
> - if it did, there would be a description in the spec - there isn't any.
>
> What effect nonOverridable has is on the reference that has nonOverridable
> on it. It basically says whether a promotion obliterates any other targets
> the reference may have or whether the promotion simply adds targets. The
> DEFAULT is obliteration. ie if you promote a reference then the target
> identified by the higher level component is what actually gets used. Only
> if nothing is supplied at the higher level could a target on the lower level
> get used (and that is the purpose of this bit complexity - it gives a
> default (local) target in the case the higher level component does not
> configure one.
>
> The relation between the higher level component reference and the lower
> level component reference that is promoted is essentially captured in this
> statement in section 4.3.1:
>
> "6. Through the promotion of a component reference by a composite
> reference of the composite containing the component (the target service is
> then identified by the configuration of the composite reference)"
>
> and "configuration" here means the configuration supplied by the component
> using the composite as an implementation (there is other material that
> covers the generalalities of how a component configuration configures ANY
> implementation - and that applies equally to composite implementations as it
> does to Java or any other type.
>
> If targets are specified on the outer level and the inner level, then what
> is supposed to happen is described in the section that deals with
> nonOverridable - and there are 2 cases:
>
> 1) "If @nonOverridable==false, if any target(s) are configured onto the
> composite references which promote the component reference, then those
> targets replace all the targets explicitly declared on the component
> reference for any value of @multiplicity on the component reference. If no
> targets are defined on any of the composite references which promote the
> component reference, then any 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."
>
>
> 2) "If @nonOverridable==true, and the component reference @multiplicity is
> 0..n or 1..n, any targets configured onto the composite references which
> promote the component reference are added to any references declared on the
> component reference - that is, the targets are additive."
>
> ...now here note that "targets" are meant in the sense implied in 4.3.1 - a
> target service specified by any means - @target, binding @uri, <wire/>
> element (note: autowire is excluded by definition since it can only come
> into play where there is NO other way of establishing a target).
>
> So - this would mean for example that if the lower level reference had <
> binding.ws uri="foobar"/>,
> but was promoted and the higher level component configured the (higher
> level) reference with @target="SomeComponent/**SomeService", then there
> would be one and only one target for the lower level reference - the
> SomeComponent/SomeService service as configured by the higher level,
> assuming nonOveridable=false (the default).
>
>
>> 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.
>>
>
> But this only applies to the bindings on the COMPONENT reference and
> whether any bindings are picked up (by defaulting) from the implementation
> of the COMPONENT.
>
> Whether ANY of these bindings get used to identify target services depends
> on the OTHER configuration of the reference - and in particular on whether
> the reference is promoted. If its promoted, then in the default case, all
> the "local" configuration of the reference like the bindings is obliterated.
> (If nonOverridable is set true, then this is not the case, since everything
> then is additive)
>
>
>
>> So where is this equivalence between binding uri and reference target
>> stated? Does it apply just to
>> binding.sca or to all bindings?
>>
>> In my opinion, this equivalence is defined in section 4.3.1, which
> declares 7 ways in which a target service can be configured for a reference.
> @target is one way. A binding with some resolved target is another. @uri
> is ONE way for a binding to have a resolved target (only way for
> binding.sca, but other ways are available for other bindings, such as a
> pointer to some WSDL service element for binding.ws).
>
>
> PS I agree that this is complex. I tried to keep nonOverridable out of the
> spec but I lost.
>
