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