On Fri, Dec 9, 2011 at 2:24 PM, Simon Laws simonsl...@googlemail.com wrote:
On Fri, Dec 9, 2011 at 2:16 PM, ant elder antel...@apache.org wrote:
On Fri, Dec 9, 2011 at 2:04 PM, Simon Laws simonsl...@googlemail.com wrote:
On Fri, Dec 9, 2011 at 1:46 PM, ant elder antel...@apache.org wrote:
On Thu, Dec 8, 2011 at 5:39 PM, Simon Laws simonsl...@googlemail.com
wrote:
On Thu, Dec 8, 2011 at 4:22 PM, ant elder ant.el...@gmail.com wrote:
On Thu, Dec 8, 2011 at 10:57 AM, Simon Nash n...@apache.org 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
ServiceReferenceHelloworld 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
That's what I was saying at the end (I think) that we make the
facility available regardless but turning wiredByImpl on means that
you have to use it. It you don't turn wiredByImpl on you can either
set the reference through the new API or rely on the target in the
SCDL.
I've committed some changes so that you can use some Tuscany versions
of the OASIS ComponentContext and ServiceReference interfaces. There's
an example of them being used to dynamically alter a Web service
reference URL at:
