Feel free to submit a bug report, but as there are not many using
XMLBeans today it may take a while for it to get fixed. I recommend
giving us a *very* simple (minimal) Maven project[1] that duplicates the
problem--something we type in "mvn clean install" and can immediately
see the problem in the target directory artifacts.
I'd also recommend switching to JAXB if you can. This will give you
much more freedom by allowing you to move to JAXB-only Metro in the
future if you wish, and you can switch from the JAXB RI to MOXy (the
newer JAXB implementation) if you wish. Also, JAXB is what most use
today, so there's a much larger pool of people on the CXF user's list
who can answer your questions.
Glen
[1] http://www.jroller.com/gmazza/entry/soap_client_tutorial,
http://www.jroller.com/gmazza/entry/java_first_web_service
On 08/08/2012 01:33 AM, Hannes Holtzhausen wrote:
Would this qualify as an issue? And if so, should I rather log it on
JIRA for it to be tracked?
On Sat, Aug 4, 2012 at 10:01 AM, Hannes Holtzhausen
<[email protected]> wrote:
I am using the Apache CXF 2.3.11 java2ws tool to generate WSDL
documents using the following configuration:
* JAX-WS frontend
* XMLBeans databinding
I decided to upgrade the tool chain to make use of CXF 2.6.1 using the
same configuration as above. Unfortunately
java2ws now generates duplicate elements in the "service" schema of
the WSDL. Below is the process I follow:
1. Define schema:
* Header schema:
<xsd:schema
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:hdr="http://javatoolbox.sf.net/services/util/header/beans";
targetNamespace="http://javatoolbox.sf.net/services/util/header/beans";
elementFormDefault="qualified">
<xsd:complexType name="ServiceHeader">
<xsd:sequence>
...
</xsd:sequence>
</xsd:complexType>
...
</xsd:schema>
* Message schema:
<?xml version="1.0" encoding="UTF-8" ?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:mep="java:mep.service.data"
targetNamespace="java:mep.service.data"
elementFormDefault="qualified">
<xsd:complexType name="InputData">
<xsd:sequence>
<xsd:sequence>
...
</xsd:sequence>
</xsd:complexType>
...
</xsd:schema>
XMLBeans is used to generate an API from the schema documents.
2. Define Java interface with JAX-WS annotations:
@WebService(name = "MEPService",
serviceName = "MEPService",
targetNamespace = "java:mep.service")
public interface MEPService
{
@WebMethod (action = "sayHello")
@WebResult (name = "OutputData",
targetNamespace = "java:mep.service")
public OutputData sayHello(
@WebParam (name = "InputData",
targetNamespace = "java:mep.service")
InputData input,
@WebParam (
name = "ServiceHeader",
targetNamespace="http://javatoolbox.sf.net/services/util/header/beans";,
header= true)
Holder<ServiceHeader> header) throws MEPServiceException;
}
The important thing to note here is that I am defining the "InputData"
WebParam in the "service" namespace, while the "ServiceHeader"
WebParam is referenced using the element's namespace as it was defined
in the header schema document above.
3. Execute java2ws:
I execute java2ws as follows:
/opt/asf/cxf23/java2ws -databinding xmlbeans -frontend jaxws -wsdl -o
mepService.cxf23_b.wsdl -cp mep_service.jar:mep_data.jar: -d .
mep.service.MEPService
/opt/asf/cxf26/java2ws -databinding xmlbeans -frontend jaxws -wsdl -o
mepService.cxf23_a.wsdl -cp mep_service.jar:mep_data.jar: -d .
mep.service.MEPService
Output:
With CXF 2.3 the the "service" schema in the WSDL only contains
element definitions for InputData and OutputData e.g:
<xsd:element name="sayHello" type="tns:sayHello"/>
<xsd:complexType name="sayHello">
<xsd:sequence>
<xsd:element form="qualified" minOccurs="0" name="InputData"
type="ns0:InputData"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="sayHelloResponse" type="tns:sayHelloResponse"/>
<xsd:complexType name="sayHelloResponse">
<xsd:sequence>
<xsd:element form="qualified" minOccurs="0" name="OutputData"
type="ns0:OutputData"/>
</xsd:sequence>
</xsd:complexType>
And the ServiceHeader element is only referenced in the WSDL messages e.g:
<wsdl:message name="sayHello">
<wsdl:part name="parameters" element="tns:sayHello">
</wsdl:part>
<wsdl:part name="ServiceHeader" element="ns1:ServiceHeader">
</wsdl:part>
</wsdl:message>
With CXF 2.6, in addition to the InputData and OutputData elements,
additional elements (one for each input and output complexType) are
defined in the "service" schema
based on the ServiceHeader type e.g:
<xsd:element name="ServiceHeader" type="ns1:ServiceHeader"/>
<xsd:element name="sayHello" type="tns:sayHello"/>
<xsd:complexType name="sayHello">
<xsd:sequence>
<xsd:element form="qualified" minOccurs="0" name="InputData"
type="ns0:InputData"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="ServiceHeader" type="ns1:ServiceHeader"/>
<xsd:element name="sayHelloResponse" type="tns:sayHelloResponse"/>
<xsd:complexType name="sayHelloResponse">
<xsd:sequence>
<xsd:element form="qualified" minOccurs="0" name="OutputData"
type="ns0:OutputData"/>
</xsd:sequence>
</xsd:complexType>
You can clearly see the "service" schema now contains additional
ServiceHeader element definitions and they are duplicated.
The ServiceHeader element is still referenced correctly in the WSDL
messages as before.
Questions/Problems:
1. Why is CXF 2.6.1 generating a ServiceHeader in the "service"
schema? This was not the default behaviour of 2.3 even though
the 2.6.1 behaviour is more consistent with what the
ServiceFactories do by default.
2. The 2.6.1 generated WSDL's (even though they would contain
ServiceHeader elements that would never be used) would still
be valid if only 1 ServiceHeader element definition was added to
the service schema. The current situation however causes schema
validation to fail with a "Duplicate Key" exception, because
ServiceHeader is defined multiple times in the same namespace.
3. Is there anything I can do from a configuration perspective to
restore the 2.3 behaviour in 2.6.1?
Hannes
