Detelin Yordanov created AXIS2-5672:
---------------------------------------
Summary: Addressing Action attributes are parsed incorrectly when
deploying service from WSDL
Key: AXIS2-5672
URL: https://issues.apache.org/jira/browse/AXIS2-5672
Project: Axis2
Issue Type: Bug
Components: Addressing, kernel
Affects Versions: 1.6.2
Reporter: Detelin Yordanov
When creating a web service out of a WSDL which contains WS-Addressing Action
attributes with format <prefix>:<value>, Axis2 will strip the "<prefix>:" part
if the document contains a namespace declaration for <prefix> on some of the
parent element. For example, if the definition element contains the following
namespace declaration:
xmlns:http="http://schemas.xmlsoap.org/wsdl/http/";
And operation's input contains a wsaw:Action that starts with "http:":
<wsdl:input message="ns:getVersionRequest"
wsam:Action="http://axisversion.sample/VersionPortType/getVersionWSAMRequest"/>
Then the result would be that the input AxisMessage is configured with an
incorrect Action value of
"//axisversion.sample/VersionPortType/getVersionWSAMRequest".
I'm attaching a patch that also contains a test case to verify this behavior -
please see WSDL11ToAxisServiceBuilderTest.testGetVersionActions() method.
I investigated the issue and I think this is caused by WSDL4J assuming
wsaw:Action attribute's value is of QName type and thus tries to parse it as
such, expecting that it might have a namespace prefix. I think this is wrong
and WSDL4J has to be configured to process wsaw:Action values as simple
literals rather than QNames. I have added a utility method for that, see:
WSDLUtil.registerDefaultExtensionAttributeTypes
This will register all WS-Addressing Action attribute flavors (for each known
namespace) in WSDL Extension registry to be of String type. For this to work,
the so configured ExtensionRegistry must be used whenever a WSDLReader is
created, therefore I added an additional utility method to be used for creating
WSDLReader instances:
WSDLUtil.newWSDLReaderWithPopulatedExtensionRegistry
I have replaced the regular WSDLFactory.newWSDLReader calls throughout Axis2
codebase with this new factory method.
While doing this, I noticed that in the past this issue might have been
identified and fixed in Axis2 CodeGenerationEngine alone:
https://svn.apache.org/viewvc?view=revision&revision=1003032
The attached patch is basically similar, but it would fix all other places in
Axis2 code where WSDLReader instance is created.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
