[jira] Assigned: (CXF-738) Duplicate schema element issue

["jimma (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CXF-738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jimma reassigned CXF-738:
-------------------------

    Assignee: jimma

> Duplicate schema element  issue
> -------------------------------
>
>                 Key: CXF-738
>                 URL: https://issues.apache.org/jira/browse/CXF-738
>             Project: CXF
>          Issue Type: Bug
>            Reporter: jimma
>            Assignee: jimma
>
> 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. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.