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
