cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: [jira] Created: (CXF-1530) Nillable parameters not rendered.
Date Tue, 22 Apr 2008 21:36:16 GMT

No.   There are two places to look depending on "where" in you schema you 
are having issues:

1) If it's in the generated "wrapper" types for wrapped doc/lit, then 
look at the three places in ReflectionServiceFactoryBean that we call 
el.setMinOccurs(..);  (just grep for setMinOccurs)

2) If it's not in one of those and is instead in the types that directly 
map to  the Aegis beans, you need to look in the aegis databinding.   
The TypeInfo stuff there has a minOccurs attribute.  I don't know enough 
about ageis to know how all that is wired though.

Dan




On Tuesday 22 April 2008, alexv wrote:
> Hi.
> My initial patch was incorrect!
> From comparing cxf-2.0.3 with cxf-2.0.5 I see that the aim is in fact
> to honour the minOccurs=0 attribute on the parameter elements. If I
> understand this correctly, XFire generates the wsdl with minOccurs=1
> and CXF with minOccurs=0 this in turn will break the compatibility
> between the to.
>
> The code that does this is as far as I can see is located in the
> ReflectionServiceFactoryBean witch is ocated in the simple frontend
> module. I changed the initializeWrappedSchema method in this class to
> iterate over the message parts in the input message and set the
> minOccurs attribute to 1. Like this:
> (Inserted betwee line 761 and 762 in the tag cxf-2.0.5-incubator)
>
>                         for (int i = 0; i <
> mi.getMessageParts().size(); i++) {
>                             final MessagePartInfo part =
> mi.getMessagePart(i);
>                             final XmlSchemaAnnotated xs =
> part.getXmlSchema();
>                             if (xs instanceof XmlSchemaElement) {
>                                 final XmlSchemaElement elem =
> (XmlSchemaElement) xs;
>                                 elem.setMinOccurs(1);
>                             }
>                         }
>
> Is this an approach to go forth with?
>
> /Alex
>
> alexv wrote:
> > What this problem boiles down to is that aegis in CXF does not
> > honour the minOccurs=1 on the parameters.
> > This is a wsdl snippet from the XFire service:
> > <xsd:element name="registrerKunde">
> >    <xsd:complexType>
> >      <xsd:sequence>
> >         <xsd:element maxOccurs="1" minOccurs="1" name="in0"
> > nillable="true" type="ns1:InputDO"/>
> >         <xsd:element maxOccurs="1" minOccurs="1" name="in1"
> > nillable="true" type="ns2:CustomerDetailDO"/>
> >         <xsd:element maxOccurs="1" minOccurs="1" name="in2"
> > nillable="true" type="ns2:SomethingDO"/>
> >        <xsd:element maxOccurs="1" minOccurs="1" name="in3"
> > nillable="true" type="ns2:ArrayOfSomethingElseDO"/>
> >    </xsd:sequence>
> >   </xsd:complexType>
> > </xsd:element>
> >
> > I have made a patch that hopefully fixes this problem and postet in
> > in jira.
> >
> > /Alex
> >
> > Benson Margulies-4 wrote:
> >> Let me make sure I'm following this. You have the same java code on
> >> both sides, and you are using Aegis on both sides. So we are all
> >> hoping that Aegis comes to the same conclusions in both the XFire
> >> and CXF versions.
> >>
> >> As the person who made the most recent changes to Aegis, I am very
> >> pessimistic about this. I strongly recommend that you use wsdl2java
> >> to create a JAX-WS+JAXB client and use that, instead.
> >>
> >> There is a lot of room for discrepancies to creep in to Aegis in
> >> comparison
> >> to XFire as we fix issues. I don't think that any of us have the
> >> wherewithall to come up with a testing methodology that would
> >> ensure that your scenario keeps working.



-- 
J. Daniel Kulp
Principal Engineer, IONA
dkulp@apache.org
http://www.dankulp.com/blog

Mime
View raw message