You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by "Greg Dritschler (Created) (JIRA)" <de...@tuscany.apache.org> on 2012/03/11 19:56:38 UTC
[jira] [Created] (TUSCANY-4027) EndpointFinder is ineffective
EndpointFinder is ineffective
-----------------------------
Key: TUSCANY-4027
URL: https://issues.apache.org/jira/browse/TUSCANY-4027
Project: Tuscany
Issue Type: Bug
Affects Versions: Java-SCA-2.0
Reporter: Greg Dritschler
Priority: Minor
SCAClientFactoryImpl calls the EndpointFinder to find a matching endpoint. If the endpoint returned by EndpointFinder is local to the same JVM, SCAClientFactoryImpl then calls RuntimeComponentImpl.getServiceReference() which calls ComponentContextImpl.createSelfReference(). If the client's URI does not include a binding name, ComponentContextImpl picks the first binding. This supercedes whatever selection was made by the EndpointFinder.
I am attaching a patch that fixes the issue. It constructs a full URI based on the selection made by the EndpointFinder and passes that to RuntimeComponentImpl.getServiceReference().
This exposed another issue. The scaclient-api itest tests that a getService() using component name only is rejected with a ServiceRuntimeException if the target component implements multiple services. This is because it is ambiguous which service is desired (SCAClientFactoryImpl does not do interface matching). This was being enforced in ComponentContextImpl, but with the above fix that isn't possible since it now gets a fully-specified URI. In order to fix this, I added a check into DefaultEndpointFinder.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TUSCANY-4027) EndpointFinder is ineffective
Posted by "Simon Laws (Assigned) (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-4027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Simon Laws reassigned TUSCANY-4027:
-----------------------------------
Assignee: Simon Laws
> EndpointFinder is ineffective
> -----------------------------
>
> Key: TUSCANY-4027
> URL: https://issues.apache.org/jira/browse/TUSCANY-4027
> Project: Tuscany
> Issue Type: Bug
> Affects Versions: Java-SCA-2.0
> Reporter: Greg Dritschler
> Assignee: Simon Laws
> Priority: Minor
> Attachments: TUSCANY-4027.patch
>
>
> SCAClientFactoryImpl calls the EndpointFinder to find a matching endpoint. If the endpoint returned by EndpointFinder is local to the same JVM, SCAClientFactoryImpl then calls RuntimeComponentImpl.getServiceReference() which calls ComponentContextImpl.createSelfReference(). If the client's URI does not include a binding name, ComponentContextImpl picks the first binding. This supercedes whatever selection was made by the EndpointFinder.
> I am attaching a patch that fixes the issue. It constructs a full URI based on the selection made by the EndpointFinder and passes that to RuntimeComponentImpl.getServiceReference().
> This exposed another issue. The scaclient-api itest tests that a getService() using component name only is rejected with a ServiceRuntimeException if the target component implements multiple services. This is because it is ambiguous which service is desired (SCAClientFactoryImpl does not do interface matching). This was being enforced in ComponentContextImpl, but with the above fix that isn't possible since it now gets a fully-specified URI. In order to fix this, I added a check into DefaultEndpointFinder.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-4027) EndpointFinder is ineffective
Posted by "Simon Laws (Closed) (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-4027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Simon Laws closed TUSCANY-4027.
-------------------------------
Resolution: Fixed
Fix Version/s: Java-SCA-2.0
Thanks for the patch Greg, Committed at revision: 1299664
> EndpointFinder is ineffective
> -----------------------------
>
> Key: TUSCANY-4027
> URL: https://issues.apache.org/jira/browse/TUSCANY-4027
> Project: Tuscany
> Issue Type: Bug
> Affects Versions: Java-SCA-2.0
> Reporter: Greg Dritschler
> Assignee: Simon Laws
> Priority: Minor
> Fix For: Java-SCA-2.0
>
> Attachments: TUSCANY-4027.patch
>
>
> SCAClientFactoryImpl calls the EndpointFinder to find a matching endpoint. If the endpoint returned by EndpointFinder is local to the same JVM, SCAClientFactoryImpl then calls RuntimeComponentImpl.getServiceReference() which calls ComponentContextImpl.createSelfReference(). If the client's URI does not include a binding name, ComponentContextImpl picks the first binding. This supercedes whatever selection was made by the EndpointFinder.
> I am attaching a patch that fixes the issue. It constructs a full URI based on the selection made by the EndpointFinder and passes that to RuntimeComponentImpl.getServiceReference().
> This exposed another issue. The scaclient-api itest tests that a getService() using component name only is rejected with a ServiceRuntimeException if the target component implements multiple services. This is because it is ambiguous which service is desired (SCAClientFactoryImpl does not do interface matching). This was being enforced in ComponentContextImpl, but with the above fix that isn't possible since it now gets a fully-specified URI. In order to fix this, I added a check into DefaultEndpointFinder.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TUSCANY-4027) EndpointFinder is ineffective
Posted by "Greg Dritschler (Updated) (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-4027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Greg Dritschler updated TUSCANY-4027:
-------------------------------------
Attachment: TUSCANY-4027.patch
> EndpointFinder is ineffective
> -----------------------------
>
> Key: TUSCANY-4027
> URL: https://issues.apache.org/jira/browse/TUSCANY-4027
> Project: Tuscany
> Issue Type: Bug
> Affects Versions: Java-SCA-2.0
> Reporter: Greg Dritschler
> Priority: Minor
> Attachments: TUSCANY-4027.patch
>
>
> SCAClientFactoryImpl calls the EndpointFinder to find a matching endpoint. If the endpoint returned by EndpointFinder is local to the same JVM, SCAClientFactoryImpl then calls RuntimeComponentImpl.getServiceReference() which calls ComponentContextImpl.createSelfReference(). If the client's URI does not include a binding name, ComponentContextImpl picks the first binding. This supercedes whatever selection was made by the EndpointFinder.
> I am attaching a patch that fixes the issue. It constructs a full URI based on the selection made by the EndpointFinder and passes that to RuntimeComponentImpl.getServiceReference().
> This exposed another issue. The scaclient-api itest tests that a getService() using component name only is rejected with a ServiceRuntimeException if the target component implements multiple services. This is because it is ambiguous which service is desired (SCAClientFactoryImpl does not do interface matching). This was being enforced in ComponentContextImpl, but with the above fix that isn't possible since it now gets a fully-specified URI. In order to fix this, I added a check into DefaultEndpointFinder.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira