On 8/15/07, Simon Laws <[EMAIL PROTECTED]> wrote: > > > > On 8/15/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > > > Raymond Feng wrote: > > > Comments inline. > > > > > > Thanks, > > > Raymond > > > > > > ----- Original Message ----- From: "Simon Laws" > > > <[EMAIL PROTECTED] > > > > To: "tuscany-dev" <tuscany-dev@ws.apache.org> > > > Sent: Tuesday, August 14, 2007 12:37 AM > > > Subject: Late resolution of reference targets - was:Accessing global > > > domain information > > > > > > > > >> Currently in CompositeWireBuilderImpl.connectComponentReference all > > >> targets > > >> are converted to bindings on a reference and the targets are > > >> removed. During this process the source and target bindings are > > compared > > >> until matching wireable bindings are found. > > >> > > > > > > This is not always possible because some of the targets are not > > > resolvable at this point. > > > > > >> Currently only the sca binding implements WireableBinding. I've > > opened > > >> https://issues.apache.org/jira/browse/TUSCANY-1534 about this. > > >> > > >> If the domain is distributed then at the build stage some of the > > targets > > >> will remain unresolved. For the new sca binding I have made the > > >> assumption > > >> here that unresolved targets take a copy of the bindings they may be > > >> resolved against at a later date and that the targets are maintained > > >> on the > > >> reference after the build stage. I still assume that the SCA binding > > >> is the > > >> only valid wireable binding at present. > > >> > > > > > > I start to look into this area too from a different perspetive. Please > > > > > see > > > > > http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Service+References > > . > > > > > > > > >> So I'm proposing that > > >> > > >> 1. The builder should retain the list of unresolved targets for use > > >> after > > >> the build stage > > >> 2. The list of bindings that might be used to resolve a target at a > > >> later > > >> date are associated with each target > > >> > > > > > > +1. What will the data structure look like? There are some cases that > > > mixed styles are used to define the binding endpoint if the reference > > > multiplicity is greater than 1 and promotion is used. For example, we > > > can have the following: > > > > > > InnerComposite: > > > <composite name="InnerComposite" ..> > > > <component name="C1 ...> > > > <reference name="myRef" target="C2/S1 C3/S1"> > > > <binding.sca/> > > > <binding.x/> > > > </reference> > > > </component> > > > > > > <component name="C2 ...> > > > ... > > > </component> > > > > > > <component name="C3 ...> > > > ... > > > </component> > > > > > > <reference name="myOuterRef" promote="C1/myRef"> > > > <binding.y> > > > </reference> > > > </composite> > > > > > > <composite name="OuterComposite" ...> > > > <component name="C4" implementation.composite="ns1:InnerComposite"> > > > <reference name="myOuterRef" target="C5/S1"/> > > > </component> > > > ... > > > <component name="C5 ...> > > > ... > > > </component> > > > </composite> > > > > > > Then the effective wires for myRef will be: > > > > > > C2/S1 (binding.sca/binidng.x), C3/S1 (binding.sca/binding.x), C5/S1 > > > (binidng.y) > > > > > > > > >> Come wire creation time care must be take to create remote wires for > > >> unresolved targets. What I do at the moment is: > > >> > > >> CompositeActivatorImpl.addReferenceBindingProviders > > >> As before, create providers for all bindings that represent > > >> resolved > > >> targets > > >> > > >> For all unresolved targets > > >> If support is enabled create a cloned SCA binding and add > > >> it to > > >> the reference binding list (so that a wire will be created). > > >> This is pretty much what goes on in the > > >> CompositeWireBuilder > > >> but I've delayed it until here in the expectation that we will do > > remote > > >> binding matching one wireable support is fixed > > >> Create an SCA binding provider which will look up the > > remote > > >> endpoint at start() time. > > >> > > >> Thoughts? > > >> > > >> Regards > > >> > > >> Simon > > >> > > > > > > > Sorry, but I'm having trouble understanding all this, it's starting to > > get a little complicated for me... Could somebody please give a *short* > > summary of the scenario that this is attempting to cover? Thanks. > > > > -- > > Jean-Sebastien > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > Raymond is coming at the problem from a different direction to me so > I'll let him give examples. For me the scenario is > > <composite ... name="HelloWorld"> > <component name="HelloWorldClient"> > <implementation.java class="HelloWorldClient" /> > <reference name="helloWorldService" target="HelloWorldService" /> > </component> > </composite> > > Where HelloWorldService does not appear in the loaded contributions. > > Simon > Hi, as an alternative to this is there a way that we can just create all the bindings/wires for the unresolved targets and then select the correct wire either when the invocation handler is created or even as late as when the first call is made through a reference.
I've been thinking about this because it is clear that we don't know how long in the future it will be before a target is available to be resolved. In this case of references that cross node boundaries it can be any time from when the composite is loaded through to the point a which the first call is made, i.e. we don;t want to prevent the composite from starting up. Regards Simon
