You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Greg Dritschler <gr...@gmail.com> on 2011/08/03 21:37:13 UTC
getting TooManyReferenceTargets when overriding binding uri of
promoted reference
I have the following composites:
Composite A has a component reference myService with binding.sca uri="X".
The reference is promoted.
Composite B has a component that uses A as its implementation. It redefines
reference myService and specifies binding.sca uri="Y".
I get the error
[ASM50022] Too many targets on reference: myService
I've found that EndpointReferenceBuilderImpl.pushDownEndpointReferences() is
adding the endpoint references from the outer component reference to the
inner component reference. This doesn't seem like it applies in this case.
My understanding is that bindings configured on the outer component
reference override bindings that would otherwise have been inherited from
the promoted reference. pushDownEndpointReferences() was introduced in
revision 833132 which says:
"Fix motivated by ASM-5023. Update code to reflect the OASIS treatment
of promoted references. Endpoint references are now copied down to the
promoted component reference and the multiplicity validation is performed
there."
ASM-5023 uses reference target. If I were using reference target instead of
binding uri, then I would agree I have an error (assuming multiplicity 0..n
or 1..n), since reference targets are additive. But I'm not using reference
target.
Greg
Re: getting TooManyReferenceTargets when overriding binding uri of
promoted reference
Posted by Mike Edwards <mi...@gmail.com>.
On 04/08/2011 10:27, Simon Laws wrote:
> On Wed, Aug 3, 2011 at 8:37 PM, Greg Dritschler
> <gr...@gmail.com> wrote:
>> I have the following composites:
>> Composite A has a component reference myService with binding.sca uri="X".
>> The reference is promoted.
>> Composite B has a component that uses A as its implementation. It redefines
>> reference myService and specifies binding.sca uri="Y".
>> I get the error
>> [ASM50022] Too many targets on reference: myService
>> I've found that EndpointReferenceBuilderImpl.pushDownEndpointReferences() is
>> adding the endpoint references from the outer component reference to the
>> inner component reference. This doesn't seem like it applies in this case.
>> My understanding is that bindings configured on the outer component
>> reference override bindings that would otherwise have been inherited from
>> the promoted reference. pushDownEndpointReferences() was introduced in
>> revision 833132 which says:
>> "Fix motivated by ASM-5023. Update code to reflect the OASIS treatment
>> of promoted references. Endpoint references are now copied down to the
>> promoted component reference and the multiplicity validation is performed
>> there."
>> ASM-5023 uses reference target. If I were using reference target instead of
>> binding uri, then I would agree I have an error (assuming multiplicity 0..n
>> or 1..n), since reference targets are additive. But I'm not using reference
>> target.
>> Greg
>>
>
> Hi Greg
>
> I think the only useful URI on a reference binding.sca is the name of
> a target service. This is equivalent to specifying the same target
> service via the target attribute. I think though that you're arguing
> that the top level binding configuration should override the lower
> level binding configuration?
>
> Simon
>
>
Folks,
Let's be clear about the use of @uri on <binding.sca>.
IF you specify @target on the parent <binding> - then it is not valid to use <binding> subelements:
"If a reference has a value specified for one or more target services in its @target attribute,
there MUST NOT be any child <binding/> elements declared for that reference. [ASM50026]"
(Section 4.3.1 Assembly spec)
so then IF you have a reference which allows multiple targets and you require a mixture of bindings,
where some of them must be resolved bindings (eg reference is to an external web service known via
its address) but others are desired to be <binding.sca>, then necessarily the only way of doing this
is to use the @uri attribute on a <binding.sca> element:
<reference name="foo" multiplicity="1..n">
<binding.sca uri="SomeComponent/SomeService"/>
<binding.ws uri="http://something.com/another/service"/>
</reference>
Hope this makes things a bit clearer.
Yours, Mike.
Re: getting TooManyReferenceTargets when overriding binding uri of
promoted reference
Posted by Simon Laws <si...@googlemail.com>.
On Thu, Aug 4, 2011 at 2:27 PM, Greg Dritschler
<gr...@gmail.com> 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.
> On Thu, Aug 4, 2011 at 5:27 AM, Simon Laws <si...@googlemail.com>
> wrote:
>>
>> On Wed, Aug 3, 2011 at 8:37 PM, Greg Dritschler
>> <gr...@gmail.com> wrote:
>> > I have the following composites:
>> > Composite A has a component reference myService with binding.sca
>> > uri="X".
>> > The reference is promoted.
>> > Composite B has a component that uses A as its implementation. It
>> > redefines
>> > reference myService and specifies binding.sca uri="Y".
>> > I get the error
>> > [ASM50022] Too many targets on reference: myService
>> > I've found that
>> > EndpointReferenceBuilderImpl.pushDownEndpointReferences() is
>> > adding the endpoint references from the outer component reference to the
>> > inner component reference. This doesn't seem like it applies in this
>> > case.
>> > My understanding is that bindings configured on the outer component
>> > reference override bindings that would otherwise have been inherited
>> > from
>> > the promoted reference. pushDownEndpointReferences() was introduced in
>> > revision 833132 which says:
>> > "Fix motivated by ASM-5023. Update code to reflect the OASIS
>> > treatment
>> > of promoted references. Endpoint references are now copied down to the
>> > promoted component reference and the multiplicity validation is
>> > performed
>> > there."
>> > ASM-5023 uses reference target. If I were using reference target
>> > instead of
>> > binding uri, then I would agree I have an error (assuming multiplicity
>> > 0..n
>> > or 1..n), since reference targets are additive. But I'm not using
>> > reference
>> > target.
>> > Greg
>> >
>>
>> Hi Greg
>>
>> I think the only useful URI on a reference binding.sca is the name of
>> a target service. This is equivalent to specifying the same target
>> service via the target attribute. I think though that you're arguing
>> that the top level binding configuration should override the lower
>> level binding configuration?
>>
>> Simon
>>
>>
>> --
>> Apache Tuscany committer: tuscany.apache.org
>> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>
>
So the rules for reference target promotion
965 Where a component reference is promoted by a composite reference,
the promotion MUST be treated
966 from a multiplicity perspective as providing 0 or more target
services for the component reference,
967 depending upon the further configuration of the composite
reference. These target services are in
968 addition to any target services identified on the component
reference itself, subject to the rules relating to
969 multiplicity. [ASM50025]
don't apply when the reference target is specified via a binding.sca
uri? Probably a question for Mike.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: getting TooManyReferenceTargets when overriding binding uri of
promoted reference
Posted by Greg Dritschler <gr...@gmail.com>.
Yes, that's the text that was bothering me. It isn't very well worded.
Anyway I think we're ok.
On Fri, Aug 12, 2011 at 11:19 AM, Simon Laws <si...@googlemail.com>wrote:
> On Fri, Aug 12, 2011 at 1:10 PM, Greg Dritschler
> <gr...@gmail.com> wrote:
> > I thought this over again, and based on everything Mike has said, I think
> my
> > proposed fix is wrong. pushDownEndpointReferences() is adding targets
> from
> > a component reference to its "leaf" component reference. This should
> always
> > be an add operation, never a replace. That's why ASM_5023 is now
> failing.
> >
> > nonOverridable only applies between the composite ref and its promoted
> > component ref within the same composite. So far I haven't found the code
> > where the targets are resolved between a composite ref and its promoted
> > component ref.
> > Greg
> > On Mon, Aug 8, 2011 at 10:46 AM, Simon Laws <si...@googlemail.com>
> > wrote:
> >>
> >> i've created https://issues.apache.org/jira/browse/TUSCANY-3912 to
> >> cover this. From the set of four failures I originally saw on a full
> >> build three are some bogus HTTP endpoint failure. The remaining is
> >> TUSCNAY-5023 which we need to look at.
> >>
> >> Simon
> >>
> >> --
> >> Apache Tuscany committer: tuscany.apache.org
> >> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
> >
> >
>
> Greg, I think you're having the same doubts that I was having when I
> suggested that the previous example was wrong. I concluded that they
> were correct after all and for me it hinged on what you say here
> "nonOverridable only applies between the composite ref and its
> promoted component ref within the same composite". I read the
> following part of the assembly spec twice:
>
> 862 • nonOverridable : boolean (0..1) - a boolean value, "false" by
> default, which indicates whether this
> 863 component reference can have its targets overridden by a composite
> reference which promotes the
> 864 component reference.
>
> First time I read it I thought it was being very specific in talking
> about "composite reference". i.e the composite reference declaration
> in the same composite. That's when I started to worry. The second time
> I read it, along with what Mike had said, I came to the conclusion
> that it meant the composite reference in the wider sense, i.e. as
> configured by the top level component.
>
> Does that make any sense?
>
> Simon
>
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>
Re: getting TooManyReferenceTargets when overriding binding uri of
promoted reference
Posted by Simon Laws <si...@googlemail.com>.
On Fri, Aug 12, 2011 at 1:10 PM, Greg Dritschler
<gr...@gmail.com> wrote:
> I thought this over again, and based on everything Mike has said, I think my
> proposed fix is wrong. pushDownEndpointReferences() is adding targets from
> a component reference to its "leaf" component reference. This should always
> be an add operation, never a replace. That's why ASM_5023 is now failing.
>
> nonOverridable only applies between the composite ref and its promoted
> component ref within the same composite. So far I haven't found the code
> where the targets are resolved between a composite ref and its promoted
> component ref.
> Greg
> On Mon, Aug 8, 2011 at 10:46 AM, Simon Laws <si...@googlemail.com>
> wrote:
>>
>> i've created https://issues.apache.org/jira/browse/TUSCANY-3912 to
>> cover this. From the set of four failures I originally saw on a full
>> build three are some bogus HTTP endpoint failure. The remaining is
>> TUSCNAY-5023 which we need to look at.
>>
>> Simon
>>
>> --
>> Apache Tuscany committer: tuscany.apache.org
>> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>
>
Greg, I think you're having the same doubts that I was having when I
suggested that the previous example was wrong. I concluded that they
were correct after all and for me it hinged on what you say here
"nonOverridable only applies between the composite ref and its
promoted component ref within the same composite". I read the
following part of the assembly spec twice:
862 • nonOverridable : boolean (0..1) - a boolean value, "false" by
default, which indicates whether this
863 component reference can have its targets overridden by a composite
reference which promotes the
864 component reference.
First time I read it I thought it was being very specific in talking
about "composite reference". i.e the composite reference declaration
in the same composite. That's when I started to worry. The second time
I read it, along with what Mike had said, I came to the conclusion
that it meant the composite reference in the wider sense, i.e. as
configured by the top level component.
Does that make any sense?
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: getting TooManyReferenceTargets when overriding binding uri of
promoted reference
Posted by Greg Dritschler <gr...@gmail.com>.
I thought this over again, and based on everything Mike has said, I think my
proposed fix is wrong. pushDownEndpointReferences() is adding targets from
a component reference to its "leaf" component reference. This should always
be an add operation, never a replace. That's why ASM_5023 is now failing.
nonOverridable only applies between the composite ref and its promoted
component ref within the same composite. So far I haven't found the code
where the targets are resolved between a composite ref and its promoted
component ref.
Greg
On Mon, Aug 8, 2011 at 10:46 AM, Simon Laws <si...@googlemail.com>wrote:
>
> i've created https://issues.apache.org/jira/browse/TUSCANY-3912 to
> cover this. From the set of four failures I originally saw on a full
> build three are some bogus HTTP endpoint failure. The remaining is
> TUSCNAY-5023 which we need to look at.
>
> Simon
>
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>
Re: getting TooManyReferenceTargets when overriding binding uri of
promoted reference
Posted by Simon Laws <si...@googlemail.com>.
On Mon, Aug 8, 2011 at 2:08 PM, Simon Laws <si...@googlemail.com> wrote:
> On Fri, Aug 5, 2011 at 10:49 PM, Greg Dritschler
> <gr...@gmail.com> wrote:
>> 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
>> <mi...@gmail.com> wrote:
>>>
>>> Greg,
>>>
>
> OK I re-read what Mike said and I'm back in the "I think the examples
> are correct" camp. Hmmmm.
>
> Greg, I gave the suggested change a go and I see a few issues with a
> full build. Am going through them now so I'll post with details.
>
> Regards
>
> Simon
>
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>
i've created https://issues.apache.org/jira/browse/TUSCANY-3912 to
cover this. From the set of four failures I originally saw on a full
build three are some bogus HTTP endpoint failure. The remaining is
TUSCNAY-5023 which we need to look at.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: getting TooManyReferenceTargets when overriding binding uri of
promoted reference
Posted by Simon Laws <si...@googlemail.com>.
On Fri, Aug 5, 2011 at 10:49 PM, Greg Dritschler
<gr...@gmail.com> wrote:
> 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
> <mi...@gmail.com> wrote:
>>
>> Greg,
>>
OK I re-read what Mike said and I'm back in the "I think the examples
are correct" camp. Hmmmm.
Greg, I gave the suggested change a go and I see a few issues with a
full build. Am going through them now so I'll post with details.
Regards
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: getting TooManyReferenceTargets when overriding binding uri of
promoted reference
Posted by Greg Dritschler <gr...@gmail.com>.
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.inglenook@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.
>
Re: getting TooManyReferenceTargets when overriding binding uri of
promoted reference
Posted by Simon Laws <si...@googlemail.com>.
On Fri, Aug 5, 2011 at 4:53 PM, Mike Edwards
<mi...@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.
>
Hmmm, now I'm not sure whether the example I posted is right or not.
Specifically because of this debate about if/how the specification of
nonOverrideable has an impact on the resulting targets for the runtime
component. I didn't show the composite reference overriding the
default provided by the promoted component reference and I suspect
that's where the examples go wrong.
I'll re-read what Mike said and try and be more precise but this seems
to be more tricky than I thought it was.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: getting TooManyReferenceTargets when overriding binding uri of
promoted reference
Posted by Mike Edwards <mi...@gmail.com>.
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.
Re: getting TooManyReferenceTargets when overriding binding uri of
promoted reference
Posted by Greg Dritschler <gr...@gmail.com>.
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 <si...@googlemail.com>wrote:
> On Thu, Aug 4, 2011 at 4:44 PM, Greg Dritschler
> <gr...@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
> > <mi...@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
>
Re: getting TooManyReferenceTargets when overriding binding uri of
promoted reference
Posted by Simon Laws <si...@googlemail.com>.
On Thu, Aug 4, 2011 at 4:44 PM, Greg Dritschler
<gr...@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
> <mi...@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
Re: getting TooManyReferenceTargets when overriding binding uri of
promoted reference
Posted by Greg Dritschler <gr...@gmail.com>.
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.inglenook@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.
>
>
>
Re: getting TooManyReferenceTargets when overriding binding uri of
promoted reference
Posted by Mike Edwards <mi...@gmail.com>.
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.
Re: getting TooManyReferenceTargets when overriding binding uri of
promoted reference
Posted by Greg Dritschler <gr...@gmail.com>.
>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.
On Thu, Aug 4, 2011 at 5:27 AM, Simon Laws <si...@googlemail.com>wrote:
> On Wed, Aug 3, 2011 at 8:37 PM, Greg Dritschler
> <gr...@gmail.com> wrote:
> > I have the following composites:
> > Composite A has a component reference myService with binding.sca uri="X".
> > The reference is promoted.
> > Composite B has a component that uses A as its implementation. It
> redefines
> > reference myService and specifies binding.sca uri="Y".
> > I get the error
> > [ASM50022] Too many targets on reference: myService
> > I've found that EndpointReferenceBuilderImpl.pushDownEndpointReferences()
> is
> > adding the endpoint references from the outer component reference to the
> > inner component reference. This doesn't seem like it applies in this
> case.
> > My understanding is that bindings configured on the outer component
> > reference override bindings that would otherwise have been inherited from
> > the promoted reference. pushDownEndpointReferences() was introduced in
> > revision 833132 which says:
> > "Fix motivated by ASM-5023. Update code to reflect the OASIS
> treatment
> > of promoted references. Endpoint references are now copied down to the
> > promoted component reference and the multiplicity validation is performed
> > there."
> > ASM-5023 uses reference target. If I were using reference target instead
> of
> > binding uri, then I would agree I have an error (assuming multiplicity
> 0..n
> > or 1..n), since reference targets are additive. But I'm not using
> reference
> > target.
> > Greg
> >
>
> Hi Greg
>
> I think the only useful URI on a reference binding.sca is the name of
> a target service. This is equivalent to specifying the same target
> service via the target attribute. I think though that you're arguing
> that the top level binding configuration should override the lower
> level binding configuration?
>
> Simon
>
>
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>
Re: getting TooManyReferenceTargets when overriding binding uri of
promoted reference
Posted by Simon Laws <si...@googlemail.com>.
On Wed, Aug 3, 2011 at 8:37 PM, Greg Dritschler
<gr...@gmail.com> wrote:
> I have the following composites:
> Composite A has a component reference myService with binding.sca uri="X".
> The reference is promoted.
> Composite B has a component that uses A as its implementation. It redefines
> reference myService and specifies binding.sca uri="Y".
> I get the error
> [ASM50022] Too many targets on reference: myService
> I've found that EndpointReferenceBuilderImpl.pushDownEndpointReferences() is
> adding the endpoint references from the outer component reference to the
> inner component reference. This doesn't seem like it applies in this case.
> My understanding is that bindings configured on the outer component
> reference override bindings that would otherwise have been inherited from
> the promoted reference. pushDownEndpointReferences() was introduced in
> revision 833132 which says:
> "Fix motivated by ASM-5023. Update code to reflect the OASIS treatment
> of promoted references. Endpoint references are now copied down to the
> promoted component reference and the multiplicity validation is performed
> there."
> ASM-5023 uses reference target. If I were using reference target instead of
> binding uri, then I would agree I have an error (assuming multiplicity 0..n
> or 1..n), since reference targets are additive. But I'm not using reference
> target.
> Greg
>
Hi Greg
I think the only useful URI on a reference binding.sca is the name of
a target service. This is equivalent to specifying the same target
service via the target attribute. I think though that you're arguing
that the top level binding configuration should override the lower
level binding configuration?
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com