cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <...@envoisolutions.com>
Subject Duplicate schema elements [was Fwd: How to invoke a CXF endpoint from a WCF client ?]
Date Mon, 18 Jun 2007 04:14:04 GMT
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
> >
> >
> >
>
>


-- 
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

-- 
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message