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:[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.
>>
>> -- 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
>> >
>> >
>> >
>>
>>
>
>
