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
