You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Benson Margulies <bi...@gmail.com> on 2008/04/16 13:05:07 UTC
Re: [jira] Created: (CXF-1530) Nillable parameters not rendered.
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.
Re: [jira] Created: (CXF-1530) Nillable parameters not rendered.
Posted by Daniel Kulp <dk...@apache.org>.
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
Re: [jira] Created: (CXF-1530) Nillable parameters not rendered.
Posted by alexv <al...@exense.com>.
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.
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Re%3A--jira--Created%3A-%28CXF-1530%29-Nillable-parameters-not-rendered.-tp16721282p16824719.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: [jira] Created: (CXF-1530) Nillable parameters not rendered.
Posted by alexv <al...@exense.com>.
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.
>
>
--
View this message in context: http://www.nabble.com/Re%3A--jira--Created%3A-%28CXF-1530%29-Nillable-parameters-not-rendered.-tp16721282p16740825.html
Sent from the cxf-dev mailing list archive at Nabble.com.