cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Mazza <gma...@talend.com>
Subject Re: Duplicate element definition upgrading from 2.3 to 2.6
Date Wed, 08 Aug 2012 12:52:22 GMT
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
> <hannes.holtzhausen@gmail.com> 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


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message