[CXF-738] Duplicate schema element issue

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 2.0
• Assignee: Jim Ma
• Reporter: Jim Ma
• Created: 18/Jun/07 08:33
• Updated: 29/Aug/07 18:10
• Resolved: 19/Jun/07 04:03

Description

I was looking into this and I found that we have at least one test which
shows a slightly different variation of the same problem. If you add these
lines to the CodeFirstTest. you'll get failures:

assertValid("//xsd:element[@name='FooEcho2HeaderRequest'][1]", doc);
assertInvalid("//xsd:element[@name='FooEcho2HeaderRequest'][2]", doc);

Note that this is a test case which involves headers though. I suspect that
the one exemplified by Dan Connelly could be reproduced by adding a couple
operations to FooService like:

Foo echo1(Foo foo)
Foo echo2(Foo foo)

In this case CXF would create the same <xsd:element name="foo" type="foo"/>
multiple times I think. It seems both JAXBSchemaIntiailizer and
ReflectionServiceFactory are creating these wrapper elements (i.e. new
XsSchemaElement). I don't know if they're checking to see if these elements
already exist at the moment...

I think this could be considered a pretty critical bug - i.e. we need to
hold up the release until we get it fixed. I'm posting it here in case
anyone feels motivated to go through it before I get up again tomorrow
(getting a little late here) . Otherwise I'll fix it first thing
tomorrow.

Cheers,

• Dan

---------- Forwarded message ----------
From: Dan Diephouse <[e-mail]>
Date: Jun 17, 2007 10:23 PM
Subject: Re: How to invoke a CXF endpoint from a WCF client ?
To: [e-mail]

This is definitely not valid per the spec... I think this might be a problem
with the JAXBDataBinding/JAXBSchemaInitializer code.

Any chance you tried a snapshot build recently?
Thanks,

• Dan

On 6/17/07, Dan Connelly <[e-mail]> wrote:
>
> OK. Don't blame VS Express ("Orcas") just yet. The major problem
> appears to come from CXF (2.0 RC in my case).
>
> The snag shows up when Orcas runs svcutil.exe, which is does for "Add
> Service Reference ...". This is the Microsoft tool equivalent of
> wsdl2java (or wsimport).
>
> Svcutil throws errors and fails to produce any C# artifacts when the
> WSDL it reads contains 2 or more element type definitions with the same
> name. And, duplicate element types seems quite common in CXF samples
> (at least for xformat BindingType).
>
> For instance, for sample "hello_world_xml_bare" server returns the the
> following definitions in response to the ?wsdl URL:
>
> ...
> <wsdl:types>
> <xs:schema attributeFormDefault="unqualified"
> elementFormDefault="unqualified"
> targetNamespace="http://apache.org/hello_world_xml_http/bare/types">
> <xs:element name="myComplexStruct" nillable="true"
> type="tns:myComplexStructType"/>
> <xs:element name="requestType" nillable="true" type="xs:string"/>
> <xs:element name="responseType" nillable="true" type="xs:string"/>
>
> <xs:complexType name="myComplexStructType">
> <xs:sequence>
> <xs:element form="qualified" name="elem1"
> type="xs:string"/>
> <xs:element form="qualified" name="elem2"
> type="xs:string"/>
> <xs:element form="qualified" name="elem3" type="xs:int"/>
> </xs:sequence>
> </xs:complexType>
> <xs:element name="myComplexStruct" nillable="true"
> type="tns:myComplexStructType"/>
> <xs:element name="responseType" nillable="true" type="xs:string"/>
> <xs:element name="requestType" nillable="true" type="xs:string"/>
> <xs:element name="responseType" nillable="true" type="xs:string"/>
> </xs:schema>
> <xsd:schema attributeFormDefault="unqualified"
> elementFormDefault="qualified"
> targetNamespace="http://apache.org/hello_world_xml_http/bare ">
> <xsd:import
> namespace="http://apache.org/hello_world_xml_http/bare/types"/>
> <xsd:import
> namespace=" http://apache.org/hello_world_xml_http/bare/types"/>
> <xsd:element name="in" nillable="true"
> type="ns0:myComplexStructType"/>
> <xsd:element name="out" nillable="true"
> type="ns0:myComplexStructType"/>
> <xsd:element name="out" nillable="true" type="xsd:string"/>
> </xsd:schema>
> </wsdl:types>
> ...
>
>
> Note:
>
> This WSDL has 2 definitions each named myComplextType, requestType, out
> It also has 3 definitions named: responseType
>
> I suspect that the WSDL XML specification would not allow multiple
> declarations of element types with the same name.
>
> Whether or not the spec allows duplicate names, the fact it breaks the
> Microsoft tooling (which would be used frequently for client creation)
> is full justification for CXF eliminating its output of element type
> names in the synthetic WSDL.