cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Mao <james....@iona.com>
Subject Re: Duplicate schema elements [was Fwd: How to invoke a CXF endpoint from a WCF client ?]
Date Mon, 25 Jun 2007 06:45:47 GMT
Hi

Maybe the fix is just not included the SNAPSHOT of June 19.
The latest snapshot does not have the same problem.

James.

> It appears that the duplicate schema element problem is not completely 
> fixed.   I am using SNAPSHOT of June 19.
>
> As shown below, schema element "faultDetail" is duplicated in response 
> to ?wsdl requent on *hello_world* sample service from the 
> distribution.    Perhaps only fault types have the problem with 
> SNAPSHOT cxf-api-2.0-incubator-20070619.165612-29.(?) 
>
>
>        -- Dan Connelly
>
> ...
> <wsdl:types>
>         <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
>             xmlns="http://apache.org/hello_world_soap_http/types"
>             attributeFormDefault="unqualified" 
> elementFormDefault="unqualified"
>             
> targetNamespace="http://apache.org/hello_world_soap_http/types">
>             <xs:element name="faultDetail">
>                 <xs:complexType>
>                     <xs:sequence>
>                         <xs:element form="qualified" name="minor"
>                             type="xs:short" />
>                         <xs:element form="qualified" name="major"
>                             type="xs:short" />
>                     </xs:sequence>
>                 </xs:complexType>
>             </xs:element>
>             <xs:element name="greetMe">
>                 <xs:complexType>
>                     <xs:sequence>
>                         <xs:element form="qualified" name="requestType"
>                             type="xs:string" />
>                     </xs:sequence>
>                 </xs:complexType>
>             </xs:element>
>             <xs:element name="greetMeOneWay">
>                 <xs:complexType>
>                     <xs:sequence>
>                         <xs:element form="qualified" name="requestType"
>                             type="xs:string" />
>                     </xs:sequence>
>                 </xs:complexType>
>             </xs:element>
>             <xs:element name="greetMeResponse">
>                 <xs:complexType>
>                     <xs:sequence>
>                         <xs:element form="qualified" name="responseType"
>                             type="xs:string" />
>                     </xs:sequence>
>                 </xs:complexType>
>             </xs:element>
>             <xs:element name="pingMe">
>                 <xs:complexType />
>             </xs:element>
>             <xs:element name="pingMeResponse">
>                 <xs:complexType />
>             </xs:element>
>             <xs:element name="sayHi">
>                 <xs:complexType />
>             </xs:element>
>             <xs:element name="sayHiResponse">
>                 <xs:complexType>
>                     <xs:sequence>
>                         <xs:element form="qualified" name="responseType"
>                             type="xs:string" />
>                     </xs:sequence>
>                 </xs:complexType>
>             </xs:element>
>             <xs:element name="faultDetail" nillable="true" />
>             <xs:element name="faultDetail" nillable="true" />
>         </xs:schema>
>     </wsdl:types>
> ...
>
>
>
>
>
> Dan Diephouse wrote:
>> Thanks Jim!
>>
>> On 6/18/07, Jim Ma <ema@iona.com> wrote:
>>>
>>> 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