You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Dan Diephouse <da...@envoisolutions.com> on 2007/06/18 06:14:04 UTC
Duplicate schema elements [was Fwd: How to invoke a CXF endpoint from a WCF client ?]
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 <da...@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 <da...@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
> >
> >
> >
>
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: Duplicate schema elements [was Fwd: How to invoke a CXF endpoint
from a WCF client ?]
Posted by James Mao <ja...@iona.com>.
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 <em...@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 <da...@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 <da...@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
>>> >> >
>>> >> >
>>> >> >
>>> >>
>>> >>
>>> >
>>> >
>>>
>>
>>
>>
>
Re: Duplicate schema elements [was Fwd: How to invoke a CXF endpoint from a WCF client ?]
Posted by Dan Diephouse <da...@envoisolutions.com>.
Thanks Jim!
On 6/18/07, Jim Ma <em...@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 <da...@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 <da...@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
> >> >
> >> >
> >> >
> >>
> >>
> >
> >
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: Duplicate schema elements [was Fwd: How to invoke a CXF endpoint
from a WCF client ?]
Posted by Jim Ma <em...@iona.com>.
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 <da...@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 <da...@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
>> >
>> >
>> >
>>
>>
>
>