wsdl2java -d jaxrbi does not corretly handle namespace
"http://www.w3.org/XML/1998/namespace";
---------------------------------------------------------------------------------------------
Key: AXIS2-2952
URL: https://issues.apache.org/jira/browse/AXIS2-2952
Project: Axis 2.0 (Axis2)
Issue Type: Bug
Components: databinding
Affects Versions: 1.2
Environment: All platforms
Reporter: Denis Rachal
wsdl2java -d jaxrbi does not corretly handle namespace
"http://www.w3.org/XML/1998/namespace";
When using the namespace "http://www.w3.org/XML/1998/namespace"; within an XSD,
wsdl2java with binding jaxbri puts the
generated code in the incorrect package.
I have an XSD that uses "xml:lang", defined in the namespace
"http://www.w3.org/XML/1998/namespace";. Although you should not
need to declare the namespace prefix "xml" the XSD in this example does so (see
http://www.w3.org/XML/1998/namespace for
details). The WSDL2java will fail if it is not declared for this use case.
If the namespace "http://www.w3.org/XML/1998/namespace"; is explicitely declared
and included, then the JAXB classes are put
into the package "org.w3.www.xml._1998.namespace" instead of the package for
the target namespace of the XSD. In this example
"http://schemas.xmlsoap.org/ws/2004/09/enumeration";, which should be package
"org.xmlsoap.schemas.ws._2004._09.enumeration".
While this may seem to just be a bit of an annoyance, it can actually produce
errors in some cases. I have two different XSDs
that use "xml:lang" and include the "http://www.w3.org/XML/1998/namespace";
namespace. In the case where both XSDs are
referenced by a single WSDL one package is overwritten by the other during the
"wsdl2java" process and you end up with
classes in the wrong namespace. package-info.java gets overwritten when
processing the second XSD. Classes generated from the
first XSD end up with the wrong package-info.java file.
Even stranger is that if I have the two XSDs consumed by a single WSDL, the
overwrite does not always occur. Sometimes the
classes end up in the correct package for one of the XSDs. Simply by moving the
schemas and WSDLs to a new directory and
calling wsdl2java again may produce different results. Therefore I have only
documented this case as best as I can here.
WSDL file for reproducing this bug is attached:
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions
targetNamespace="http://schemas.xmlsoap.org/ws/2004/07/bug/test";
xmlns:tns="http://schemas.xmlsoap.org/ws/2004/07/bug/test";
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing";
xmlns:wsen="http://schemas.xmlsoap.org/ws/2004/09/enumeration";
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/";
xmlns:xs="http://www.w3.org/2001/XMLSchema";
xmlns:wsoap12="http://schemas.xmlsoap.org/wsdl/soap12/";>
<!-- Import external WSDL schemas -->
<wsdl:import
namespace="http://schemas.xmlsoap.org/ws/2004/09/enumeration";
location="http://schemas.xmlsoap.org/ws/2004/09/enumeration/enumeration.wsdl"; />
<wsdl:types>
<xs:schema>
<xs:import
namespace="http://schemas.xmlsoap.org/ws/2004/09/enumeration";
schemaLocation="http://schemas.xmlsoap.org/ws/2004/09/enumeration/enumeration.xsd";
/>
</xs:schema>
</wsdl:types>
<wsdl:binding name="TestBinding" type="wsen:DataSource">
<wsoap12:binding
transport="http://schemas.xmlsoap.org/soap/http";
style="document" />
<!-- Operations -->
<wsdl:operation name="EnumerateOp">
<wsoap12:operation
soapAction="http://schemas.xmlsoap.org/ws/2004/09/enumeration/Enumerate"; />
<wsdl:input>
<wsoap12:body message="wsen:EnumerateMessage"
parts="Body" use="literal" />
</wsdl:input>
<wsdl:output>
<wsoap12:body wsdl:required="true"
message="wsen:EnumerateResponseMessage"
parts="Body" use="literal" />
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="TestService">
<wsdl:documentation>
Test Service
</wsdl:documentation>
<wsdl:port name="TestResource" binding="tns:TestBinding">
<wsoap12:address
location="http://localhost:8080/test/user/"; />
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
--
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]
