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
