You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Kevin Williams <kj...@gmail.com> on 2008/04/02 19:37:22 UTC
[vtest] getCompositeContext API for non-SCA clients
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
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [vtest] getCompositeContext API for non-SCA clients
Posted by ant elder <an...@apache.org>.
On Fri, Apr 25, 2008 at 2:11 PM, Simon Laws <si...@googlemail.com>
wrote:
> On Fri, Apr 25, 2008 at 8:32 AM, ant elder <an...@gmail.com> wrote:
>
> > Sounds ok to me.
> >
> > ...ant
> >
> > On Thu, Apr 24, 2008 at 9:41 PM, Yee-Kang Chang <ye...@ca.ibm.com>
> > 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 <an...@gmail.com>
> 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 <yeekangc@ca.ibm.com
> >
> > > > 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
> > > <kj...@gmail.com>
> > > > > 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
Re: [vtest] getCompositeContext API for non-SCA clients
Posted by Simon Laws <si...@googlemail.com>.
On Fri, Apr 25, 2008 at 8:32 AM, ant elder <an...@gmail.com> wrote:
> Sounds ok to me.
>
> ...ant
>
> On Thu, Apr 24, 2008 at 9:41 PM, Yee-Kang Chang <ye...@ca.ibm.com>
> 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 <an...@gmail.com> 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 <ye...@ca.ibm.com>
> > > 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
> > <kj...@gmail.com>
> > > > 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
Re: [vtest] getCompositeContext API for non-SCA clients
Posted by ant elder <an...@gmail.com>.
Sounds ok to me.
...ant
On Thu, Apr 24, 2008 at 9:41 PM, Yee-Kang Chang <ye...@ca.ibm.com> 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 <an...@gmail.com> 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 <ye...@ca.ibm.com>
> > 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
> <kj...@gmail.com>
> > > 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
>
Re: [vtest] getCompositeContext API for non-SCA clients
Posted by ant elder <an...@gmail.com>.
On Mon, Apr 28, 2008 at 11:37 AM, Mike Edwards <
mike.edwards.inglenook@gmail.com> wrote:
> Kevin Williams wrote:
>
> > My interest here is centered around a specification-compliant means
> > for non-SCA clients to get access to SAC services. The Java
> > API/Annotation specification suggests that non-SCA client use
> > ComponentContext.getService(Class<B> businessInterface, String
> > referenceName). How a non-SCA client gets the ComponentContext is
> > left up to the implementation.
> >
> > This is a weak area of the spec which is probably why we have the
> > alternative SCADomain.getService().
> >
> > --Kevin
> >
> > On Thu, Apr 24, 2008 at 2:41 PM, Yee-Kang Chang <ye...@ca.ibm.com>
> > 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 <an...@gmail.com>
> > > 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 <
> > > yeekangc@ca.ibm.com>
> > > > 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
> > > <kj...@gmail.com>
> > > > > 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
> > >
> >
> > Folks,
>
> I'd like to make you all aware that there is a major debate on precisely
> this topic of "unmanaged code" accessing SCA functionality taking place on
> the OASIS SCA Java technical committee right now.
>
> This is under the topic "Issue 1" and there are 3 proposals on the table
> already - they don't necessarily conflict, they actually address different
> parts of the problem.
>
> See:
>
> http://lists.oasis-open.org/archives/sca-j/
>
> ...unfortunately the proposals and discussion are scattered across a
> couple of months of the archives.
>
>
> Yours, Mike.
>
Any update on this? The most recent I can see on this is
http://lists.oasis-open.org/archives/sca-j/200804/msg00005.html at the
beginning of April, has anything happened somewhere else and do you think
its likely to get resolved soon?
...ant
Re: [vtest] getCompositeContext API for non-SCA clients
Posted by Mike Edwards <mi...@gmail.com>.
Kevin Williams wrote:
> My interest here is centered around a specification-compliant means
> for non-SCA clients to get access to SAC services. The Java
> API/Annotation specification suggests that non-SCA client use
> ComponentContext.getService(Class<B> businessInterface, String
> referenceName). How a non-SCA client gets the ComponentContext is
> left up to the implementation.
>
> This is a weak area of the spec which is probably why we have the
> alternative SCADomain.getService().
>
> --Kevin
>
> On Thu, Apr 24, 2008 at 2:41 PM, Yee-Kang Chang <ye...@ca.ibm.com> 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 <an...@gmail.com> 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 <ye...@ca.ibm.com>
>> > 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
>> <kj...@gmail.com>
>> > > 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
>
Folks,
I'd like to make you all aware that there is a major debate on precisely
this topic of "unmanaged code" accessing SCA functionality taking place
on the OASIS SCA Java technical committee right now.
This is under the topic "Issue 1" and there are 3 proposals on the table
already - they don't necessarily conflict, they actually address
different parts of the problem.
See:
http://lists.oasis-open.org/archives/sca-j/
...unfortunately the proposals and discussion are scattered across a
couple of months of the archives.
Yours, Mike.
Re: [vtest] getCompositeContext API for non-SCA clients
Posted by Kevin Williams <kj...@gmail.com>.
My interest here is centered around a specification-compliant means
for non-SCA clients to get access to SAC services. The Java
API/Annotation specification suggests that non-SCA client use
ComponentContext.getService(Class<B> businessInterface, String
referenceName). How a non-SCA client gets the ComponentContext is
left up to the implementation.
This is a weak area of the spec which is probably why we have the
alternative SCADomain.getService().
--Kevin
On Thu, Apr 24, 2008 at 2:41 PM, Yee-Kang Chang <ye...@ca.ibm.com> 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 <an...@gmail.com> 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 <ye...@ca.ibm.com>
> > 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
> <kj...@gmail.com>
> > > 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
Re: [vtest] getCompositeContext API for non-SCA clients
Posted by Yee-Kang Chang <ye...@ca.ibm.com>.
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 <an...@gmail.com> 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 <ye...@ca.ibm.com>
> 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
<kj...@gmail.com>
> > 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
Re: [vtest] getCompositeContext API for non-SCA clients
Posted by Scott Kurz <sc...@gmail.com>.
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 <an...@gmail.com> 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 <ye...@ca.ibm.com>
> 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 <kj...@gmail.com>
> > 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
> >
>
Re: [vtest] getCompositeContext API for non-SCA clients
Posted by ant elder <an...@gmail.com>.
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 <ye...@ca.ibm.com> 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 <kj...@gmail.com>
> 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
>
Re: [vtest] getCompositeContext API for non-SCA clients
Posted by Yee-Kang Chang <ye...@ca.ibm.com>.
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 <kj...@gmail.com>
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
Re: [vtest] getCompositeContext API for non-SCA clients
Posted by ant elder <an...@gmail.com>.
On Wed, Apr 2, 2008 at 6:37 PM, Kevin Williams <kj...@gmail.com>
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