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
