Re: getting TooManyReferenceTargets when overriding binding uri of promoted reference
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 simonsl...@googlemail.comwrote: On Fri, Aug 12, 2011 at 1:10 PM, Greg Dritschler greg.dritsch...@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 simonsl...@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
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 simonsl...@googlemail.comwrote: 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
On Fri, Aug 12, 2011 at 1:10 PM, Greg Dritschler greg.dritsch...@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 simonsl...@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
On Fri, Aug 5, 2011 at 10:49 PM, Greg Dritschler
greg.dritsch...@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
mike.edwards.inglen...@gmail.com wrote:
Greg,
OK I re-read what Mike said and I'm back in the I think the examples
are correct camp. H.
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
On Mon, Aug 8, 2011 at 2:08 PM, Simon Laws simonsl...@googlemail.com wrote:
On Fri, Aug 5, 2011 at 10:49 PM, Greg Dritschler
greg.dritsch...@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
mike.edwards.inglen...@gmail.com wrote:
Greg,
OK I re-read what Mike said and I'm back in the I think the examples
are correct camp. H.
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
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
Re: getting TooManyReferenceTargets when overriding binding uri of promoted reference
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.comwrote: 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
Re: getting TooManyReferenceTargets when overriding binding uri of promoted reference
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
Re: getting TooManyReferenceTargets when overriding binding uri of promoted reference
On Fri, Aug 5, 2011 at 4:53 PM, 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
Re: getting TooManyReferenceTargets when overriding binding uri of promoted reference
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
Re: getting TooManyReferenceTargets when overriding binding uri of promoted reference
On Wed, Aug 3, 2011 at 8:37 PM, Greg Dritschler greg.dritsch...@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
On 04/08/2011 10:27, Simon Laws wrote: On Wed, Aug 3, 2011 at 8:37 PM, Greg Dritschler greg.dritsch...@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
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 simonsl...@googlemail.comwrote: On Wed, Aug 3, 2011 at 8:37 PM, Greg Dritschler greg.dritsch...@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
On Thu, Aug 4, 2011 at 2:27 PM, Greg Dritschler greg.dritsch...@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 simonsl...@googlemail.com wrote: On Wed, Aug 3, 2011 at 8:37 PM, Greg Dritschler greg.dritsch...@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
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
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.
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
