Thanks Jim! On 6/18/07, Jim Ma <[EMAIL PROTECTED]> 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:[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 >> > >> > >> > >> >> > >
-- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog
