Duplicate schema element issue
-------------------------------
Key: CXF-738
URL: https://issues.apache.org/jira/browse/CXF-738
Project: CXF
Issue Type: Bug
Reporter: jimma
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:[EMAIL PROTECTED]'FooEcho2HeaderRequest'][1]", doc);
assertInvalid("//xsd:[EMAIL PROTECTED]'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 <[EMAIL PROTECTED]>
Date: Jun 17, 2007 10:23 PM
Subject: Re: How to invoke a CXF endpoint from a WCF client ?
To: [EMAIL PROTECTED]
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 <[EMAIL PROTECTED]> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
