You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by "Kevin Williams (JIRA)" <tu...@ws.apache.org> on 2007/06/18 23:50:25 UTC
[jira] Created: (TUSCANY-1354) SCADomain. getService () should
follow CompositeContext.getService() conventions for "service-name"
SCADomain. getService () should follow CompositeContext.getService() conventions for "service-name"
---------------------------------------------------------------------------------------------------
Key: TUSCANY-1354
URL: https://issues.apache.org/jira/browse/TUSCANY-1354
Project: Tuscany
Issue Type: Bug
Affects Versions: Java-SCA-M2
Reporter: Kevin Williams
Fix For: Java-SCA-Next
The current SCADomain method
"public abstract <B> B getService(Class<B> businessInterface, String serviceName);"
is similar in purpose to the .95 specification for CompositeContext.locateService API. For this reason, the new API should follow the conventions established of the old API.
This is from the .95 specification:
public interface CompositeContext {
...
T locateService(Class<T> serviceType, String serviceName);
}
"serviceName" can take on one of the following forms:
<component-name>/<service-name>
If the service-name is not provided, the name of the serviceType sans package name will be used as the service-name
The current implementation getService ends up in the following code:
public <B> ServiceReference<B> getServiceReference(Class<B> businessInterface, String name) {
// Extract the component name
String componentName;
String serviceName;
int i = name.indexOf('/');
if (i != -1) {
componentName = name.substring(0, i);
serviceName = name.substring(i + 1);
} else {
componentName = name;
serviceName = null;
}
It seems that the "else" should default serviceName to businessInterface.getSimpleName() in order to follow the existing convention.
A test case will follow shortly.
--
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Closed: (TUSCANY-1354) SCADomain. getService () should
follow CompositeContext.getService() conventions for "service-name"
Posted by "Kevin Williams (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kevin Williams closed TUSCANY-1354.
-----------------------------------
Resolution: Won't Fix
Canceling since the current behavior seems in-line with the 1.0 specifications
> SCADomain. getService () should follow CompositeContext.getService() conventions for "service-name"
> ---------------------------------------------------------------------------------------------------
>
> Key: TUSCANY-1354
> URL: https://issues.apache.org/jira/browse/TUSCANY-1354
> Project: Tuscany
> Issue Type: Bug
> Affects Versions: Java-SCA-M2
> Reporter: Kevin Williams
> Fix For: Java-SCA-Next
>
>
> The current SCADomain method
> "public abstract <B> B getService(Class<B> businessInterface, String serviceName);"
> is similar in purpose to the .95 specification for CompositeContext.locateService API. For this reason, the new API should follow the conventions established of the old API.
> This is from the .95 specification:
> public interface CompositeContext {
> ...
> T locateService(Class<T> serviceType, String serviceName);
> }
> "serviceName" can take on one of the following forms:
> <component-name>/<service-name>
> If the service-name is not provided, the name of the serviceType sans package name will be used as the service-name
> The current implementation getService ends up in the following code:
> public <B> ServiceReference<B> getServiceReference(Class<B> businessInterface, String name) {
> // Extract the component name
> String componentName;
> String serviceName;
> int i = name.indexOf('/');
> if (i != -1) {
> componentName = name.substring(0, i);
> serviceName = name.substring(i + 1);
> } else {
> componentName = name;
> serviceName = null;
> }
> It seems that the "else" should default serviceName to businessInterface.getSimpleName() in order to follow the existing convention.
> A test case will follow shortly.
--
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Commented: (TUSCANY-1354) SCADomain. getService () should
follow CompositeContext.getService() conventions for "service-name"
Posted by "Paul Golick (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12507945 ]
Paul Golick commented on TUSCANY-1354:
--------------------------------------
>From reading the code that is common to DefaultSCADomain.java and EmbeddedSCADomain.java (both in package org.apache.tuscany.sca.host.embedded.impl), it appears that the "serviceName = null" assignment is used as a flag to note that the caller provided only a component-name and did not provide a service-name.
This flag is local to the getServiceReference method and is used to select which createSelfReference method of ComponentContext to choose:
createSelfReference(businessInterface) when no service-name was specified by caller
createSelfReference(businessInterface, serviceName) when caller specified the serviceName
In section 1.6.3 of SCA_JavaAnnotationsAndAPIs_V100.pdf (lines 435 and 436) it is stated: "The second variant, which takes an additional 'serviceName' parameter, must be used if the component implements multiple services."
So, the current implementation of getService allows the string parameter to specify only the component name when the component implements one service and does not require that service name to match "the name of the serviceType sans package name" as required previously.
In SCA_AssemblyModel_V100.pdf section 1.6.4 (lines 1617-1618 and 1627-1629) it is stated: "The specification of the service name is optional if the target component only has one service with a compatible interface"
Additionally, I could find no constraint on service names relating to a service type in the V100 specifications.
> SCADomain. getService () should follow CompositeContext.getService() conventions for "service-name"
> ---------------------------------------------------------------------------------------------------
>
> Key: TUSCANY-1354
> URL: https://issues.apache.org/jira/browse/TUSCANY-1354
> Project: Tuscany
> Issue Type: Bug
> Affects Versions: Java-SCA-M2
> Reporter: Kevin Williams
> Fix For: Java-SCA-Next
>
>
> The current SCADomain method
> "public abstract <B> B getService(Class<B> businessInterface, String serviceName);"
> is similar in purpose to the .95 specification for CompositeContext.locateService API. For this reason, the new API should follow the conventions established of the old API.
> This is from the .95 specification:
> public interface CompositeContext {
> ...
> T locateService(Class<T> serviceType, String serviceName);
> }
> "serviceName" can take on one of the following forms:
> <component-name>/<service-name>
> If the service-name is not provided, the name of the serviceType sans package name will be used as the service-name
> The current implementation getService ends up in the following code:
> public <B> ServiceReference<B> getServiceReference(Class<B> businessInterface, String name) {
> // Extract the component name
> String componentName;
> String serviceName;
> int i = name.indexOf('/');
> if (i != -1) {
> componentName = name.substring(0, i);
> serviceName = name.substring(i + 1);
> } else {
> componentName = name;
> serviceName = null;
> }
> It seems that the "else" should default serviceName to businessInterface.getSimpleName() in order to follow the existing convention.
> A test case will follow shortly.
--
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org