On Fri, Apr 11, 2008 at 8:16 AM, Mike Edwards <
[EMAIL PROTECTED]> wrote:
> Simon Laws wrote:
>
> > On Thu, Apr 10, 2008 at 10:45 AM, ant elder <[EMAIL PROTECTED]> wrote:
> >
> > On Thu, Apr 10, 2008 at 10:28 AM, Simon Laws <[EMAIL PROTECTED]
> > > >
> > > wrote:
> > >
> > > On Thu, Apr 10, 2008 at 9:17 AM, Wang Feng <[EMAIL PROTECTED]> wrote:
> > > >
> > > > +1 throw an exception.
> > > > >
> > > > > The scenario like this class.getMethod(methodName).
> > > > > If a matching method is not found,it will throw
> > > > >
> > > > NoSuchMethodException.
> > >
> > > > Thanks,
> > > > > Wang Feng
> > > > >
> > > > >
> > > > > On 2008-04-10,ant elder <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > TUSCANY-2145 asks about SCADomain.getService () returning a proxy
> > > > > >
> > > > > even
> > >
> > > > when
> > > > >
> > > > > > the service doesn't exist, but looking back through the SVN
> > > > > > history
> > > > > >
> > > > > it
> > >
> > > > looks
> > > > >
> > > > > > like this is intentional. Before I close the JIRA does anyone
> > > > > > have
> > > > > >
> > > > > any
> > >
> > > > comments on if this is/isn't the correct behaviour?
> > > > > >
> > > > > > ...ant
> > > > > >
> > > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > > >
> > > > > I believe this is the way it is because of the approach we took to
> > > > >
> > > > resolving references to services running remotely elsewhere in the
> > > >
> > > domain.
> > >
> > > > I.e. as a last resort we used to look them up at run time. Hence it
> > > >
> > > wasn't
> > >
> > > > until you tried to use the proxy that you found out whether the
> > > > service
> > > > was
> > > > available.
> > > >
> > > > For component to component wires this is going away now as the
> > > > workspace
> > > > resolves these wires before composites are deployed. There is still
> > > > however
> > > > the case here where some client is calling getService(). There are
> > > > two
> > > > uses
> > > > cases that come to mind:
> > > >
> > > > 1 - node.getService() - the process that is running the node asks
> > > > for a
> > > > service reference. In this case we could mandate that only services
> > > >
> > > local
> > >
> > > > to
> > > > the node are available and hence sidestep the remote lookup problem.
> > > > 2 - "domain". getService() - domain is in speech marks here as we
> > > > are
> > > > removing this interface at the moment. However I still think we will
> > > > at
> > > > some
> > > > point need the ability to allow an arbitrary non-sca client to get
> > > > at
> > > > services exposed by an SCA domain. In this case though we would now
> > > > rely
> > > > on
> > > > the workspace which has access to all of the component service
> > > > endpoint
> > > > information.
> > > >
> > > > The long and short of this is that I think that get service should
> > > > now
> > > > raise
> > > > an error if you ask for a service that doesn't exist. Preferably by
> > > > throwing
> > > > an exception. However this is tied up with unpicking some of the
> > > >
> > > existing
> > >
> > > > domain support which is still ongoing so I would leave TUSCANY-2145
> > > > open
> > > > for
> > > > the time being.
> > > >
> > > > Simon
> > > >
> > > > Is the current o.a.t.s.host.embeded.impl.SCADomainImpl actually
> > > used by
> > > any
> > > of the distributed node/domain impl code? Without having searched in
> > > the
> > > code i thought the host-embeded module was separate and if so we could
> > > change SCADomainImpl to through an exception now?
> > >
> > > ...ant
> > >
> > >
> > It is separate so we could add the exception now if everyone is happy.
> > We
> > might get away with this without breaking any tests. It's the underlying
> > callable reference code that is reused across host-embedded and the
> > distributed code.
> >
> > Simon
> >
> > Folks,
>
> Can someone help me here - I may simply not understand the new design
> point, but something does not feel right here.
>
> I believe that it must be possible to deploy a contribution to the Domain
> which has components with references to services supplied by other
> composites. If this is so, it must also be the case that the target
> component may not yet have been contributed, so that at the point the first
> component is run, its reference cannot be satisfied. It will be satisfied
> later when the second contribution is deployed.
>
> So, how is this situation being handled? Thowing an exception at load
> time for the first component does not sound right to me.
>
>
> Yours, Mike.
>
This JIRA is about the SCADomain code in the tuscany-host-embeded module and
that code doesn't support incrementally adding contributions.
So doing something like:
scaDomain =
o.a.t.s.host.embeded.SCADomain.newInstance("OuterComposite.composite"),
scaDomain.getService(Source.class, "SourceComponentXXX");
The scaDomain knows that SourceComponentXXX doesn't exist and the getService
method could throw an exception there. Right now in that situation the code
does not throw an exception but returns a proxy anyway and the exception
occurs when any service method is called on that proxy.
...ant
