One of the composite reference scenarios outlined by Jeremy has a local wire between the Component and the Reference, and an external wire from the CompositeComponent to a sibling Component or Reference (aka the "uncle"). For instance:
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"; name="OuterComposite"> <component name="SourceComponent"> <implementation.composite name="InnerComposite"/> <references> <reference name="TargetComponentRef" target="TargetComponent"/> </references> </component> <composite name="InnerComposite"> <service name="" target="InnerSourceComponent"> <interface.java interface="..."/> </service> <component name="InnerSourceComponent"> <implementation.java class="SourceImpl"/> <references> <reference name="target" target="TargetComponentRef"/> </references> </component> <reference name="TargetComponentRef"> <interface.java interface="..."/> </reference> </composite> <component name="TargetComponent"> <implementation.java class="TargetImpl"/> </component> </composite> There are two issues to consider: (1) how the composite reference "TargetComponentRef" gets modeled, and (2) how is the composite reference "TargetComponentRef" is wired by the wiring infrastructure. (1) Model and runtime objects for a targetless composite reference. A targetless composite reference does not have a binding and it is not specified by a component and given a target. So, at the model level the object that represents this kind of composite reference is not a BoundReferenceDefinition nor a ReferenceTarget, but it can be a plain ReferenceDefinition instance that is considered separately by CompositeBuilder to get its runtime representation built. In fact, ReferenceLoader seems to deal with this case already, returning a ReferenceDefinition instance when there is no binding, so it's just a matter of setting up the CompositeBuilder and registering a builder for the ReferenceDefinition with the builder registry. At the runtime level we seem to have agreed on the definition of a CompositeReference class that extends ReferenceExtension. The other piece that is needed is a builder that creates a CompositeReference, that is registered with the builder registry and that takes a ReferenceDefinition. This can't be a BindingBuilder, so it seems a new class is needed, perhaps ReferenceBuilder or CompositeReferenceBuilder. (2) Wiring a targetless composite reference. In the example above, TargetComponentRef does not specify an explicit target or a binding, its target is intended to be resolved by a component that is implemented by the composite that contains TargetComponentRef, SourceComponent in this case. When SourceComponent is being built by CompositeBuilder, a runtime representation is created for it, e.g., a CompositeComponentImpl. When an outbound wire is being added to the created CompositeComponentImpl by WireService, via the BuilderRegistry, the CompositeComponentImpl should pass on this wire to the runtime representation of TargetComponentRef, i.e., CompositeReference. This way, a CompositeComponent "shares" the outbound wire of its target with the corresponding CompositeReference. This way, the behavior of ConnectorImpl can be to just connect the outbound wire in SourceComponent's CompositeComponentImpl and not to recurse down into TargetComponentRef as it is sharing the same wire that was already connected. One question that arises is: should passing on wires happen recursively down? For instance, since the reference in InnerSourceComponent is to a composite reference, should the outbound wire given to the CompositeComponent that represents InnerSourceComponent come from the composite reference, i.e., TargetComponentRef?
