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
