[
https://issues.apache.org/jira/browse/TUSCANY-4036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Greg Dritschler updated TUSCANY-4036:
-------------------------------------
Attachment: TUSCANY-4036.patch
> WSDL service names are duplicated when user does not provide WSDL
> -----------------------------------------------------------------
>
> Key: TUSCANY-4036
> URL: https://issues.apache.org/jira/browse/TUSCANY-4036
> Project: Tuscany
> Issue Type: Bug
> Affects Versions: Java-SCA-2.0
> Reporter: Greg Dritschler
> Priority: Minor
> Attachments: TUSCANY-4036.patch
>
>
> Scenario: An SCA composite has multiple components which
> * use binding.ws
> * do not provide a WSDL document via the wsdlElement attribute
> * implement the same Java interface
> In this case, for each web service binding, WSDLServiceGenerator takes the
> WSDL Definition that is generated by Interface2WSDLGenerator and adds a WSDL
> service and port to it. In this scenario where multiple components
> implement the same interface, the resulting WSDL services have the same
> definition namespace (which is derived from the Java package name) and the
> same local name (which is derived from the Java class name). This may make
> it difficult for the runtime to tailor the WSDL to support component-specific
> policy.
> This problem does not exist when the user does provide WSDL (either via
> wsdlElement or interface.wsdl). In that case WSDLServiceGenerator creates a
> new WSDL Definition with a modified namespace that includes the component
> name. This is possible because the generated WSDL can import the user's WSDL
> document. It is more difficult to do this in the problem scenario because
> WSDLServiceGenerator is already working with a generated document that has no
> physical location for the import to refer to.
> An alternate solution is for WSDLServiceGenerator to include the component
> name in the WSDL service name.
>
--
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
