On Fri, Apr 25, 2008 at 2:11 PM, Simon Laws <[EMAIL PROTECTED]> wrote:
> On Fri, Apr 25, 2008 at 8:32 AM, ant elder <[EMAIL PROTECTED]> wrote: > > > Sounds ok to me. > > > > ...ant > > > > On Thu, Apr 24, 2008 at 9:41 PM, Yee-Kang Chang <[EMAIL PROTECTED]> > > wrote: > > > > > Thanks, Scott, Ant. I think both could work. Perhaps we can start > with > > > getComponentContext(String componentURI) and go from there? > > > > > > I gather a client will typically connect to a domain first and then > work > > > with its components? If so, adding getComponentContext() to SCADomain > > can > > > be a good start? > > > > > > -- > > > > > > Kevin, Yee-Kang, > > > > > > Did you envision creating a new API that would accept a component URI > as > > > input, > > > e.g.: > > > ComponentContext getComponentContext(String componentURI); > > > > > > Or were you talking about some sort of virtual component like Ant > > > mentioned? > > > Scott > > > > > > > > > On Thu, Apr 24, 2008 at 10:49 AM, ant elder <[EMAIL PROTECTED]> > wrote: > > > > Ok, although with non-SCA clients which component would that be? > Does > > > there > > > > need to be a new something like implementation.web but for JSE > > clients? > > > or > > > > could there be a "virtual" component that has references for all the > > > > toplevel component services in the domain (which is kind of what we > > have > > > > now > > > > with SCADomain.getService right?). > > > > > > > > ...ant > > > > > > > > On Thu, Apr 17, 2008 at 9:10 PM, Yee-Kang Chang <[EMAIL PROTECTED] > > > > > > wrote: > > > > > > > > > Just thought to follow-up to see if we will do this .. > > > > > > > > > > Perhaps SCADomain can be extended to return the ComponentContext > for > > a > > > > > particular component? > > > > > > > > > > Thanks. > > > > > > > > > > On Wed, Apr 2, 2008 at 6:37 PM, Kevin Williams > > > <[EMAIL PROTECTED]> > > > > > wrote: > > > > > > The current JUnit tests (iTest and vTest) make use of the > > > non-standard > > > > > > SCADomain.getService API to get a handle to an SCA service. Are > > > there > > > > > > any plans to provide an API to get a ComponentContext as > outlined > > by > > > > > > the SCA Java Annotations and APIs specification? I would like > to > > > > > > stick to stick to specified APIs as much as possible in vTest. > > > > > > > > > > > > > > > > > > 1.4.2.1. ComponentContext > > > > > > Non-SCA client code can use the ComponentContext API to perform > > > > > > operations against a component in an > > > > > > SCA domain. How client code obtains a reference to a > > > ComponentContext > > > > > > is runtime specific. The following > > > > > > example demonstrates the use of the component Context API by > > non-SCA > > > > > code: > > > > > > > > > > > > ComponentContext context = // obtained through host > > > > > > environment-specific means > > > > > > > > > > > > HelloService helloService = > > > > > > context.getService(HelloService.class,"HelloService"); > > > > > > > > > > > > Thanks. > > > > > > -- > > > > > > Kevin > > > > > > > > > > I don't remember any discussion about this so i guess there are > "no > > > > plans" > > > > > yet to change it. I agree it seems like we should though. > > > > > > > > > > ...ant > > > > > > > Hi > > Implementing the spec described API for getting at service reference > sounds > like a good idea to me. However the semantics of the ComponentContext > differ from what we are used to on SCADomain and SCANode. For example, > > SCADomain.getService(serviceName) - currently provides a proxy to the > requested service in the local runtime > ComponentContext.getService(referenceName) - returns the proxy for the > named > reference of the service to which the context refers > > So it will take a bit of getting used to. The equivalent of > > serviceProxy = SCADomain.getService(interface, serviceName) > > being > > context = SCADomain.getComponentContext(componentName) > serviceProxy = context.createSelfRefence(interface, serviceName) > > Perhaps, more importantly, the implications of getServiceReference() are > different as the reference returned is a reference of the component rather > than a reference to the component. From there you could go and set > conversation and callback details on that reference. Not sure this is bad > but it's certainly different from what we are used to. I'm also not sure > that getRequestContext() would ever return anything useful in this case. > > Is it the intention that a context can be retrieved for a component that > is > not running in the local runtime, i.e. is running remotely somewhere else > in > the domain? This is problematic because the majority of the > ComponentContext > interface relies on some undisclosed protocol to get at information such > as > properties and references. I think getting a reference to the service is > doable as we can reasonably expect to be able to talk to the component > service remotely. However a better approach could be to restrict component > context retrieval to local components and then rely on access to local > component references to access remote components. > > Just my initial impression... > > Simon > > [1] > > http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/sca-api/src/main/java/org/osoa/sca/ComponentContext.java > Doesn't the "virtual" component that has references for all the component services in the (local?) domain help with some of those issues? The API would then be quite similar to what we have now - serviceProxy = SCADomain.getComponentContext().getService(interface, serviceName) ...ant
