You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Alexander Vaagan (JIRA)" <ji...@apache.org> on 2008/04/16 12:55:25 UTC
[jira] Created: (CXF-1530) Nillable parameters not rendered.
Nillable parameters not rendered.
---------------------------------
Key: CXF-1530
URL: https://issues.apache.org/jira/browse/CXF-1530
Project: CXF
Issue Type: Bug
Affects Versions: 2.0.5, 2.0.4, 2.0.2
Environment: Windows, Java 5, Service running on XFire, Client running CXF
Reporter: Alexander Vaagan
I have a service that accepts multiple arguments like this: MyResult getResults(ComplexInput arg0, AnOtherArgumentInput arg1).
If I one or more of these arguments are null I get a fault from the service saying Not enough message parts. I have inspected the actual soap message sent over the wire and have confirmed that the parameters are not rendered.
The service is running on XFire. (I am not able to migrate the service to CXF yet!)
The problem exists on version 2.0.2, 2.0.4 and 2.0.5, but it seems to work on version 2.0.3.
Both the service and the client uses AegisBinding. (Code first approach)
/alex
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
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.
Re: [jira] Created: (CXF-1530) Nillable parameters not rendered.
Posted by Benson Margulies <bi...@gmail.com>.
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.
[jira] Updated: (CXF-1530) Nillable parameters not rendered.
Posted by "Alexander Vaagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-1530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alexander Vaagan updated CXF-1530:
----------------------------------
Attachment: xmlstreamdatawriter.patch
Hi.
The problem is that you don't use minOccurs=0, but minOccurs=1
Here is a snippet from the wsdl:
<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 found that the XMLStreamDataWriter class does not honour the wsdl correctly thus not rendering the parameters correctly.
In our environment we definitively prefer the simple frontend over the jaxws+jaxb aproach.
I have made a patch to fix this issue....
> Nillable parameters not rendered.
> ---------------------------------
>
> Key: CXF-1530
> URL: https://issues.apache.org/jira/browse/CXF-1530
> Project: CXF
> Issue Type: Bug
> Affects Versions: 2.0.2, 2.0.4, 2.0.5
> Environment: Windows, Java 5, Service running on XFire, Client running CXF
> Reporter: Alexander Vaagan
> Attachments: xmlstreamdatawriter.patch
>
>
> I have a service that accepts multiple arguments like this: MyResult getResults(ComplexInput arg0, AnOtherArgumentInput arg1).
> If I one or more of these arguments are null I get a fault from the service saying Not enough message parts. I have inspected the actual soap message sent over the wire and have confirmed that the parameters are not rendered.
> The service is running on XFire. (I am not able to migrate the service to CXF yet!)
> The problem exists on version 2.0.2, 2.0.4 and 2.0.5, but it seems to work on version 2.0.3.
> Both the service and the client uses AegisBinding. (Code first approach)
> /alex
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-1530) Nillable parameters not rendered.
Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-1530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12589668#action_12589668 ]
Daniel Kulp commented on CXF-1530:
----------------------------------
Benson replied on cxf-dev:
http://www.nabble.com/Re:--jira--Created:-(CXF-1530)-Nillable-parameters-not-rendered.-to16721282.html
> Nillable parameters not rendered.
> ---------------------------------
>
> Key: CXF-1530
> URL: https://issues.apache.org/jira/browse/CXF-1530
> Project: CXF
> Issue Type: Bug
> Affects Versions: 2.0.2, 2.0.4, 2.0.5
> Environment: Windows, Java 5, Service running on XFire, Client running CXF
> Reporter: Alexander Vaagan
>
> I have a service that accepts multiple arguments like this: MyResult getResults(ComplexInput arg0, AnOtherArgumentInput arg1).
> If I one or more of these arguments are null I get a fault from the service saying Not enough message parts. I have inspected the actual soap message sent over the wire and have confirmed that the parameters are not rendered.
> The service is running on XFire. (I am not able to migrate the service to CXF yet!)
> The problem exists on version 2.0.2, 2.0.4 and 2.0.5, but it seems to work on version 2.0.3.
> Both the service and the client uses AegisBinding. (Code first approach)
> /alex
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CXF-1530) Nillable parameters not rendered.
Posted by "Alexander Vaagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-1530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alexander Vaagan updated CXF-1530:
----------------------------------
Attachment: xmlstreamdatawriter-trunk.patch
I was unable to get the trunk to build cleanly so I made the patch against tag cxf-2.0.5-incubator.
(The build error was unrelated to this patch. Module rt\frontend\jaxrs)
I have included a patch against the trunk.
Thanks!
/Alex
> Nillable parameters not rendered.
> ---------------------------------
>
> Key: CXF-1530
> URL: https://issues.apache.org/jira/browse/CXF-1530
> Project: CXF
> Issue Type: Bug
> Affects Versions: 2.0.2, 2.0.4, 2.0.5
> Environment: Windows, Java 5, Service running on XFire, Client running CXF
> Reporter: Alexander Vaagan
> Attachments: xmlstreamdatawriter-trunk.patch, xmlstreamdatawriter.patch
>
>
> I have a service that accepts multiple arguments like this: MyResult getResults(ComplexInput arg0, AnOtherArgumentInput arg1).
> If I one or more of these arguments are null I get a fault from the service saying Not enough message parts. I have inspected the actual soap message sent over the wire and have confirmed that the parameters are not rendered.
> The service is running on XFire. (I am not able to migrate the service to CXF yet!)
> The problem exists on version 2.0.2, 2.0.4 and 2.0.5, but it seems to work on version 2.0.3.
> Both the service and the client uses AegisBinding. (Code first approach)
> /alex
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-1530) Nillable parameters not rendered.
Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-1530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12589669#action_12589669 ]
Daniel Kulp commented on CXF-1530:
----------------------------------
For CXF's version of Aegis/Simple frontend, not having them on the wire is probably correct. By default, we use minOccurs=0 for optional stuff so they don't waste space on the wire and processing time parsing and stuff. Thus, if XFire doesn't do the same thing, they may not be able to work together.
I would definitely agree with Benson to use the wsdl and generate jaxws+jaxb clients for this.
> Nillable parameters not rendered.
> ---------------------------------
>
> Key: CXF-1530
> URL: https://issues.apache.org/jira/browse/CXF-1530
> Project: CXF
> Issue Type: Bug
> Affects Versions: 2.0.2, 2.0.4, 2.0.5
> Environment: Windows, Java 5, Service running on XFire, Client running CXF
> Reporter: Alexander Vaagan
>
> I have a service that accepts multiple arguments like this: MyResult getResults(ComplexInput arg0, AnOtherArgumentInput arg1).
> If I one or more of these arguments are null I get a fault from the service saying Not enough message parts. I have inspected the actual soap message sent over the wire and have confirmed that the parameters are not rendered.
> The service is running on XFire. (I am not able to migrate the service to CXF yet!)
> The problem exists on version 2.0.2, 2.0.4 and 2.0.5, but it seems to work on version 2.0.3.
> Both the service and the client uses AegisBinding. (Code first approach)
> /alex
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-1530) Nillable parameters not rendered.
Posted by "Benson Margulies (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-1530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12590239#action_12590239 ]
Benson Margulies commented on CXF-1530:
---------------------------------------
What version did you make this patch against? We like to modify the trunk and merge back, and I'm thinking you did this to 2.0.x since it doesn't apply to the trunk cleanly.
Could you possibly pull a tree from svn and patch that? If not, I'll try to work out how to apply your change to the trunk.
> Nillable parameters not rendered.
> ---------------------------------
>
> Key: CXF-1530
> URL: https://issues.apache.org/jira/browse/CXF-1530
> Project: CXF
> Issue Type: Bug
> Affects Versions: 2.0.2, 2.0.4, 2.0.5
> Environment: Windows, Java 5, Service running on XFire, Client running CXF
> Reporter: Alexander Vaagan
> Attachments: xmlstreamdatawriter.patch
>
>
> I have a service that accepts multiple arguments like this: MyResult getResults(ComplexInput arg0, AnOtherArgumentInput arg1).
> If I one or more of these arguments are null I get a fault from the service saying Not enough message parts. I have inspected the actual soap message sent over the wire and have confirmed that the parameters are not rendered.
> The service is running on XFire. (I am not able to migrate the service to CXF yet!)
> The problem exists on version 2.0.2, 2.0.4 and 2.0.5, but it seems to work on version 2.0.3.
> Both the service and the client uses AegisBinding. (Code first approach)
> /alex
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-1530) Nillable parameters not rendered.
Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-1530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12590959#action_12590959 ]
Daniel Kulp commented on CXF-1530:
----------------------------------
The patch is definitely not correct.
final XmlSchemaAnnotated schema = part.getXmlSchema();
if (schema instanceof XmlSchemaElement
&& ((XmlSchemaElement) schema).getSchemaType() instanceof XmlSchemaComplexType) {
XmlSchemaElement se = (XmlSchemaElement) schema;
if (se.getSchemaType() instanceof XmlSchemaComplexType) {
final XmlSchemaComplexType sct = (XmlSchemaComplexType) se.getSchemaType();
final XmlSchemaParticle particle = sct.getParticle();
minOccurs = particle.getMinOccurs();
} else {
minOccurs = ((XmlSchemaElement) part.getXmlSchema()).getMinOccurs();
}
}
This ends up getting the minOccurs on the XmlSchemaParticle, which in your case is the <sequence> element. That defaults to 1. Also, the "else" clause above is never hit at all.
Is there anyway to get a reproduceable test case?
Dan
> Nillable parameters not rendered.
> ---------------------------------
>
> Key: CXF-1530
> URL: https://issues.apache.org/jira/browse/CXF-1530
> Project: CXF
> Issue Type: Bug
> Affects Versions: 2.0.2, 2.0.4, 2.0.5
> Environment: Windows, Java 5, Service running on XFire, Client running CXF
> Reporter: Alexander Vaagan
> Attachments: xmlstreamdatawriter-trunk.patch, xmlstreamdatawriter.patch
>
>
> I have a service that accepts multiple arguments like this: MyResult getResults(ComplexInput arg0, AnOtherArgumentInput arg1).
> If I one or more of these arguments are null I get a fault from the service saying Not enough message parts. I have inspected the actual soap message sent over the wire and have confirmed that the parameters are not rendered.
> The service is running on XFire. (I am not able to migrate the service to CXF yet!)
> The problem exists on version 2.0.2, 2.0.4 and 2.0.5, but it seems to work on version 2.0.3.
> Both the service and the client uses AegisBinding. (Code first approach)
> /alex
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.