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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
