Re: [vtest] getCompositeContext API for non-SCA clients

[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