[
https://issues.apache.org/jira/browse/AXIS2-5732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14987174#comment-14987174
]
Detelin Yordanov commented on AXIS2-5732:
-----------------------------------------
The issue requires fix in wsdl4j as well as in Axis2. I created a patch for the
mentioned wsdl4j bug by using the source already provided by the reporter and
also added a couple of unit tests. I'm unable to attach the patch in wsdl4j
jira, probably it is already closed, therefore I'm attaching it here
(wsdl4j.patch). The patched wsdl4j version would ensure the binding's port type
is correctly populated. After adopting this wsdl4j version, Axis2 should drop
its recursive search for the port type (which in this case results in the
'undefined' port type found in the bindings.wsdl) and rely on wsdl4j to
correctly set it on the binding.
I was hesitant to change Axis2 wsdl parsing not to search for the port type
recursively, so I examined the history behind this approach in attempt to
identify the use cases for which it was added. I have found the following
checkins in Axis2 which introduced and improved this search over the years:
1. Long time ago, WSDL4JImportedWSDLHelper was introduced in Axis2, which aimed
to process the imports and find out the concrete definition where each element
is defined, then copy/merge it in the top-most definition:
https://svn.apache.org/viewvc/webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/wsdl/util/WSDL4JImportedWSDLHelper.java?revision=552171&view=markup&pathrev=590599
2. Later Amila discovered that this breaks the "useOriginalWsdl" support and
improved that NOT to copy/merge elements, but to identify source definition for
each element:
https://svn.apache.org/viewvc?view=revision&revision=552753
3. Further on (7 years ago), this was improved and generalized:
https://svn.apache.org/viewvc?view=revision&revision=590599
But still, I have no clue why this is necessary. I checked other web service
engines (CXF) and they seem to rely in wsdl4j to properly parse the wsdl. From
my perspective this is the way to go, since wsdl4j is responsible for doing
exactly that.
At the end, I prepared a fix for Axis2 that will drop the recursive search only
for the port type but retain that for the binding. I'm attaching axis2.patch
(done against Axis2 1.6.3), which also contains a test case for this issue.
Both the wsdl4j and axis2 patch should resolve this problem and hopefully not
cause any regressions.
> WSDL11ToAxisServiceBuilder fails to determine the MEP when wsdl bindings are
> defined in an imported document
> ------------------------------------------------------------------------------------------------------------
>
> Key: AXIS2-5732
> URL: https://issues.apache.org/jira/browse/AXIS2-5732
> Project: Axis2
> Issue Type: Bug
> Components: kernel, wsdl
> Affects Versions: 1.6.3
> Reporter: Detelin Yordanov
> Attachments: EchoService.aar, stacktrace.txt
>
>
> When deploying a web service archive with 'useOriginalwsdl=true' and a wsdl
> which imports the bindings from another document, the
> WSDL11ToAxisServiceBuilder fails with "Cannot Determine the MEP" exception.
> The issue seems to be caused by wsdl4j which does not properly populate
> binding's port type operations, this is reported in wsdl4j jira:
> https://sourceforge.net/p/wsdl4j/bugs/39/
> Additionally, since Axis2 will do a depth-first search in imported wsdls to
> find the port type, it will not use the port type in the parent wsdl, but the
> unpopulated/undefined port type in the bindings' wsdl.
> I'm providing an 'EchoService.aar' that demonstrates the issue - please raise
> Axis2 log level to DEBUG to see the exception.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
