[jira] Closed: (TUSCANY-2145) SCADomain.getService () should throw exception when bogus component name is passed
[
https://issues.apache.org/jira/browse/TUSCANY-2145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Laws closed TUSCANY-2145.
---
Resolution: Later
I'm going to close this a working as designed, i.e. to take account of
unresolved references. However new work is starting on a new spec compliant API
and I expect this subject will be revisited there.
> SCADomain.getService () should throw exception when bogus component name is
> passed
> --
>
> Key: TUSCANY-2145
> URL: https://issues.apache.org/jira/browse/TUSCANY-2145
> Project: Tuscany
> Issue Type: Bug
> Components: Java SCA Core Runtime
>Affects Versions: Java-SCA-Next
>Reporter: Kevin Williams
>Priority: Minor
>
> SCADomain.getService() currently returns a proxy even when the component name
> passed is not in the domain.
> I have created a test (currently "ignored") in the new vTest suite to
> demonstrate.
> @Test
> @Ignore
> public void bogusComponentName() throws Exception {
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: SCADomain.getService () should throw exception when bogus component name is passed?
On Thu, Apr 24, 2008 at 8:49 AM, Simon Laws <[EMAIL PROTECTED]>
wrote:
>
>
> On Thu, Apr 24, 2008 at 8:08 AM, ant elder <[EMAIL PROTECTED]> wrote:
>
> > I'm going to close TUSCANY-2145 as working as designed in a few days
> > unless
> > someone says otherwise.
> >
> > I still get the feeling that there is actually no way for
> > o.a.t.s.host.imbedded.impl.DefaultSCADomain to find any new services at
> > invocation time so it could just throw the exception as suggested in the
> > JIRA, but it seems harder to prove that than to just go with the flow
> > and
> > keep the current behaviour.
> >
> > ...ant
> >
> > On Sun, Apr 13, 2008 at 3:35 PM, Yang Lei <[EMAIL PROTECTED]> wrote:
> >
> > > I think we should keep the following piece. As the comment
> > > said,"create a remote service ref" , so it can delegate to the binding
> > > implementation to handle remote case.
> > >
> > >// Lookup the component in the domain
> > >Component component =
> > componentManager.getComponent(componentName);
> > >if (component == null) {
> > >// The component is not local in the partition, try to
> > > create a remote service ref
> > >return createServiceReference(businessInterface, name);
> > >}
> > >
> > > I agree if we already find the component ( component !=null case), we
> > > should check if the service is defined on the component and throw the
> > > service not found exception if it is not defined. I think the current
> > > implementation already does it in the ComponentContextImpl...
> > >
> > > Yang.
> > >
> > > On Thu, Apr 10, 2008 at 4: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]
> > > >
> > > >
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
>
> Hi Ant
>
> I agree with the sentiment that given the way that we have the code in
> Tuscany organized at the moment there is no way for DefaultSCADomain to find
> any new service at invocation time. However in the past we have have had
> Nodes that have allowed this and I'm currently changing the builder code [1]
> to allow for this more generally in the future. So I agree we should just
> close this JIRA with the expectation that, in the future, returning a
> reference that is not, yet, resolved is a useful feature.
>
> Simon
>
oops, forgot the reference which talks about some experiments to make the
binding of references more flexible. I'm not done just yet but I hope to
check some code in shortly that we can take a look at and discuss to see if
we think it's a sensible thing to do i.e. move from a brainstorm into a
concrete feature.
[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg30805.html
Re: SCADomain.getService () should throw exception when bogus component name is passed?
On Thu, Apr 24, 2008 at 8:08 AM, ant elder <[EMAIL PROTECTED]> wrote:
> I'm going to close TUSCANY-2145 as working as designed in a few days
> unless
> someone says otherwise.
>
> I still get the feeling that there is actually no way for
> o.a.t.s.host.imbedded.impl.DefaultSCADomain to find any new services at
> invocation time so it could just throw the exception as suggested in the
> JIRA, but it seems harder to prove that than to just go with the flow and
> keep the current behaviour.
>
> ...ant
>
> On Sun, Apr 13, 2008 at 3:35 PM, Yang Lei <[EMAIL PROTECTED]> wrote:
>
> > I think we should keep the following piece. As the comment
> > said,"create a remote service ref" , so it can delegate to the binding
> > implementation to handle remote case.
> >
> >// Lookup the component in the domain
> >Component component =
> componentManager.getComponent(componentName);
> >if (component == null) {
> >// The component is not local in the partition, try to
> > create a remote service ref
> >return createServiceReference(businessInterface, name);
> >}
> >
> > I agree if we already find the component ( component !=null case), we
> > should check if the service is defined on the component and throw the
> > service not found exception if it is not defined. I think the current
> > implementation already does it in the ComponentContextImpl...
> >
> > Yang.
> >
> > On Thu, Apr 10, 2008 at 4: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]
> > >
> > >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
Hi Ant
I agree with the sentiment that given the way that we have the code in
Tuscany organized at the moment there is no way for DefaultSCADomain to find
any new service at invocation time. However in the past we have have had
Nodes that have allowed this and I'm currently changing the builder code [1]
to allow for this more generally in the future. So I agree we should just
close this JIRA with the expectation that, in the future, returning a
reference that is not, yet, resolved is a useful feature.
Simon
Re: SCADomain.getService () should throw exception when bogus component name is passed?
I'm going to close TUSCANY-2145 as working as designed in a few days unless
someone says otherwise.
I still get the feeling that there is actually no way for
o.a.t.s.host.imbedded.impl.DefaultSCADomain to find any new services at
invocation time so it could just throw the exception as suggested in the
JIRA, but it seems harder to prove that than to just go with the flow and
keep the current behaviour.
...ant
On Sun, Apr 13, 2008 at 3:35 PM, Yang Lei <[EMAIL PROTECTED]> wrote:
> I think we should keep the following piece. As the comment
> said,"create a remote service ref" , so it can delegate to the binding
> implementation to handle remote case.
>
>// Lookup the component in the domain
>Component component = componentManager.getComponent(componentName);
>if (component == null) {
>// The component is not local in the partition, try to
> create a remote service ref
>return createServiceReference(businessInterface, name);
>}
>
> I agree if we already find the component ( component !=null case), we
> should check if the service is defined on the component and throw the
> service not found exception if it is not defined. I think the current
> implementation already does it in the ComponentContextImpl...
>
> Yang.
>
> On Thu, Apr 10, 2008 at 4: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]
> >
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
Re: SCADomain.getService () should throw exception when bogus component name is passed?
I think we should keep the following piece. As the comment
said,"create a remote service ref" , so it can delegate to the binding
implementation to handle remote case.
// Lookup the component in the domain
Component component = componentManager.getComponent(componentName);
if (component == null) {
// The component is not local in the partition, try to
create a remote service ref
return createServiceReference(businessInterface, name);
}
I agree if we already find the component ( component !=null case), we
should check if the service is defined on the component and throw the
service not found exception if it is not defined. I think the current
implementation already does it in the ComponentContextImpl...
Yang.
On Thu, Apr 10, 2008 at 4: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]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCADomain.getService () should throw exception when bogus component name is passed?
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(So
Re: SCADomain.getService () should throw exception when bogus component name is passed?
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]
Re: SCADomain.getService () should throw exception when bogus component name is passed?
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
Re: SCADomain.getService () should throw exception when bogus component name is passed?
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
Re: SCADomain.getService () should throw exception when bogus component name is passed?
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
Re: SCADomain.getService () should throw exception when bogus component name is passed?
+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]
SCADomain.getService () should throw exception when bogus component name is passed?
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
[jira] Commented: (TUSCANY-2145) SCADomain.getService () should throw exception when bogus component name is passed
[
https://issues.apache.org/jira/browse/TUSCANY-2145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12587513#action_12587513
]
ant elder commented on TUSCANY-2145:
This behaviour was introduced in r570929 -
http://svn.apache.org/viewvc?view=rev&revision=570929 so it looks like it is
intentional. I'll bring it up on the dev list but right now looks like this
will be closed as Working-As-Designed.
> SCADomain.getService () should throw exception when bogus component name is
> passed
> --
>
> Key: TUSCANY-2145
> URL: https://issues.apache.org/jira/browse/TUSCANY-2145
> Project: Tuscany
> Issue Type: Bug
> Components: Java SCA Core Runtime
>Affects Versions: Java-SCA-Next
>Reporter: Kevin Williams
>Priority: Minor
>
> SCADomain.getService() currently returns a proxy even when the component name
> passed is not in the domain.
> I have created a test (currently "ignored") in the new vTest suite to
> demonstrate.
> @Test
> @Ignore
> public void bogusComponentName() throws Exception {
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-2145) SCADomain.getService () should throw exception when bogus component name is passed
SCADomain.getService () should throw exception when bogus component name is
passed
--
Key: TUSCANY-2145
URL: https://issues.apache.org/jira/browse/TUSCANY-2145
Project: Tuscany
Issue Type: Bug
Components: Java SCA Core Runtime
Affects Versions: Java-SCA-Next
Reporter: Kevin Williams
Priority: Minor
SCADomain.getService() currently returns a proxy even when the component name
passed is not in the domain.
I have created a test (currently "ignored") in the new vTest suite to
demonstrate.
@Test
@Ignore
public void bogusComponentName() throws Exception {
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
