cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Ma <...@iona.com>
Subject Re: Duplicate schema elements [was Fwd: How to invoke a CXF endpoint from a WCF client ?]
Date Mon, 18 Jun 2007 13:26:09 GMT
Hi Dan ,

I have fixed this issue with this commit : 
http://svn.apache.org/viewvc?view=rev&rev=548344 .

--Jim


Dan Diephouse wrote:
> 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 <dan@envoisolutions.com>
> Date: Jun 17, 2007 10:23 PM
> Subject: Re: How to invoke a CXF endpoint from a WCF client ?
> To: cxf-user@incubator.apache.org
>
> 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 <daniel.s.connelly@comcast.net> 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.
>>
>>        -- Dan Connelly
>>
>>
>> ------------------------------------------------------------------------------------------------------

>>
>>
>>
>> Dan Connelly wrote:
>> > Compare with:   How to invoke a WSIT endpoint from a WCF client ?
>> > <http://blogs.sun.com/arungupta/entry/how_to_invoke_a_wsit>
>> >
>> > I am trying this process but for a CXF endpoint using latest C# Visual
>> > Studio 9 Express ("Orcas") from Microsoft.
>> >
>> > I have not found a CXF sample WSDL that works cleanly with Orcas "Add
>> > Service Reference" function.
>> >
>> > Any suggestions?
>> >
>> >       -- Dan Connelly
>> >
>> >
>> >
>>
>>
>
>

Mime
View raw message