On Fri, Dec 9, 2011 at 2:04 PM, Simon Laws <[email protected]> wrote: > On Fri, Dec 9, 2011 at 1:46 PM, ant elder <[email protected]> wrote: >> On Thu, Dec 8, 2011 at 5:39 PM, Simon Laws <[email protected]> wrote: >>> On Thu, Dec 8, 2011 at 4:22 PM, ant elder <[email protected]> wrote: >>>> On Thu, Dec 8, 2011 at 10:57 AM, Simon Nash <[email protected]> wrote: >>>>> ant elder wrote: >>>>>> >>>>>> This is good and i will have a go in 2.x to see if a similar approach >>>>>> works there. But i can't help thinking its a slightly convoluted >>>>>> approach and as we have more flexibility in 2.x to add more APIs I >>>>>> wonder if we should just add a more direct API method to set the URIs >>>>>> with extra methods on Node, or also perhaps something like being able >>>>>> to do: ((TuscanyServiceReference)serviceReference).setURI(uri)? >>>>>> >>>>> +1 for providing a more convenient solution in 2.x. >>>>> >>>>> A setURI() method would only work for certain binding types. Perhaps >>>>> this could be generalized to use some kind of notion of endpoint. >>>>> >>>>> There's also the mysterious wiredByImpl notion from the SCA spec. >>>>> It might be good to use that as the base concept for this capability. >>>>> >>>> >>>> Ok i had a quick stab at this in r1211944 and 1211945 which enables >>>> setting the binding URI of a ServiceReference by casting it to >>>> org.apache.tuscany.sca.core.context.impl.ServiceReferenceImpl and >>>> calling setBindingURI. Eg >>>> >>>> ServiceReference<Helloworld> sr = >>>> componentContext.getServiceReference(Helloworld.class, >>>> "helloworldService"); >>>> >>>> ((ServiceReferenceImpl)sr).setBindingURI("http://localhost:8080/HelloworldService/Helloworld";); >>>> return "client: " + sr.getService().sayHello(name); >>>> >>>> Obviously its not ideal to be casting to a that impl class and it >>>> should rather have an API/SPI interface to cast to. I haven't done a >>>> whole lot of testing but that that seems to work ok, can anyone see >>>> any obvious issues? >>>> >>>> ...ant >>> >>> Ant >>> >>> I like the idea of being able to prod things into the service >>> reference. I have two immediate thoughts that are not well formed.... >>> >>> - Could we remove the cast by providing a Tuscany specific >>> ComponentContext for wireByImp impls. We already have the Tuscany >>> RuntimeComponentContext. >>> - Are there binding specific things we will want to do. Nothing comes >>> to mind just yet although policy configuration might be a possibility. >>> >> >> The main issue with the current cast is that its casting to an impl >> class so just using some existing or new interface to have the >> setBindingURI method and casting to that would be better, and that >> allows adding whatever else we think of that might be useful to expose >> to users. I guess an alternative or addition would be to define a >> Tuscany specific annotation to get hold of the Tuscany specific >> context instead of using the OASIS annotation. >> >> ...ant > > IIRC the OASIS annotation code is smart enough (or can be made that > way) to inject the right thing based on the Type of the field to be > injected. We could gate this algorithm based on whether the reference > is marked as wire by impl. I.e. are you allowed to affect the wiring > from within the implementation. The assembly spec says this about > wiredByImpl > > If set to "true" it indicates that the target of the > 353 reference is set at runtime by the implementation code (e.g. by > the code obtaining an endpoint > 354 reference by some means and setting this as the target of the > reference through the use of > 355 programming interfaces defined by the relevant Client and > Implementation specification).If > 356 @wiredByImpl is set to "true", then any reference targets > configured for this reference MUST be > 357 ignored by the runtime. [ASM40006] > > I've never been sure whether "implementation" here refers to the > component implementation or the component implementation type (the > infrastructure code) or either. > > I supposed there's nothing stopping us from making the feature > available regardless of whether wiredByImpl is set but. if nothing > else, we could use it to explain what wiredByImpl is for. >
The issues I have with having wiredByImpl control whether or not this is possible are that it defaults to false and if its true then you can't have a default for the reference defined in the SCDL (asm40006). Perhaps I don't understand the reasoning behind those but it seems more useable the other way around to me. ...ant
