You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by Chuck Williams <ch...@manawiz.com> on 2006/01/24 10:15:17 UTC
[Axis2-0.94] WSDL2Java generates bad code for complex types
I have a complexType that contains a <choice> of two alternative
elements, like this:
<xsd:complexType name="AorB">
<xsd:choice>
<xsd:element name="A" type="xsd:string"/>
<xsd:element name="B" type="xsd:string"/>
</xsd:choice>
</xsd:complexType>
and a reponse message that contains a value of this type:
<message name="respmessage">
<part name="resp" type="asxsd:AorB"/>
</message>
and a portType with an operation that returns the response message:
<portType name="FooPortType">
<operation name="Bar">
<input .../>
<output message="as:respmessage"/>
</operation>
</portType>
WSDL2Java generates a class AorB and requires it as content of the
respmessage to be returned from the Bar() method in the generated
FooPortTypeSkeleton. However, AorB has no setters or getters, so there
is no way to give it the A or B element to return. Also, A and B do not
extend AorB so there is no way to pass either of them directly.
How is this supposed to work?
Thanks for any help,
Chuck
Re: [Axis2-0.94] WSDL2Java generates bad code for oneway operations
Posted by Ajith Ranabahu <aj...@gmail.com>.
Hi Ruben,
Yes this is a problem in the last release. Please log a Jira. I'll anyway
have a look at it soon :)
On 1/25/06, Rubén Naranjo Izquierdo <rn...@alumnos.upm.es> wrote:
>
> Hello all,
>
> I've been working with Axis2-0.94's WSDL2Java and I found out that the
> code
> it generates for oneway operations doesn't work.
>
> If we have a wsdl with an operation like this (Where
> "tns:SimpleMessage"
> may be just a "xsd:string"):
>
> <wsdl:portType name="SimplePortType">
> <wsdl:operation name="SimpleOperation">
> <wsdl:input message="tns:SimpleMessage"/>
> </wsdl:operation>
> </wsdl:portType>
>
> WSDL2Java generates a Message Receiver that extends
> "AbstractInOutSyncMessageReceiver" instead of "AbstractInMessageReceiver":
>
> public class SimplePortTypeMessageReceiver extends
> org.apache.axis2.receivers.AbstractInOutSyncMessageReceiver { ... }
>
> Also, in the Stub, operations are registered as "OutInAxisOperation",
> instead of "InOnlyAxisOperation":
>
> _operations = new org.apache.axis2.description.OutInAxisOperation[1];
>
> Any attept to use the stub to comunicate with the service will result
> in
> the following exception:
>
> org.apache.axis2.AxisFault: org.apache.axis2.AxisFault: Raw Xml provider
> supports only the methods bearing the signature public OMElement
> <method-name>(OMElement) where the method name can be anything
>
> If we add an output message to the operation, then everything works
> perfectly (but the operation isn't oneway any more):
>
> <wsdl:portType name="SimplePortType">
> <wsdl:operation name="SimpleOperation">
> <wsdl:input message="tns:SimpleMessage"/>
> <wsdl:output message="tns:SimpleMessage"/>
> </wsdl:operation>
> </wsdl:portType>
>
> I also tried to manually change Message Receiver generated, so it
> extended
> "AbstractInMessageReceiver". But I culdn't come to a valid solution.
>
> Am I doing something wrong? Or is this a bug of Axis2-0.94? May I log a
> bug
> in Jira?
>
> Thank you in advance,
>
> Rubén
>
--
Ajith Ranabahu
[Axis2-0.94] WSDL2Java generates bad code for oneway operations
Posted by Rubén Naranjo Izquierdo <rn...@alumnos.upm.es>.
Hello all,
I've been working with Axis2-0.94's WSDL2Java and I found out that the code
it generates for oneway operations doesn't work.
If we have a wsdl with an operation like this (Where "tns:SimpleMessage"
may be just a "xsd:string"):
<wsdl:portType name="SimplePortType">
<wsdl:operation name="SimpleOperation">
<wsdl:input message="tns:SimpleMessage"/>
</wsdl:operation>
</wsdl:portType>
WSDL2Java generates a Message Receiver that extends
"AbstractInOutSyncMessageReceiver" instead of "AbstractInMessageReceiver":
public class SimplePortTypeMessageReceiver extends
org.apache.axis2.receivers.AbstractInOutSyncMessageReceiver { ... }
Also, in the Stub, operations are registered as "OutInAxisOperation",
instead of "InOnlyAxisOperation":
_operations = new org.apache.axis2.description.OutInAxisOperation[1];
Any attept to use the stub to comunicate with the service will result in
the following exception:
org.apache.axis2.AxisFault: org.apache.axis2.AxisFault: Raw Xml provider
supports only the methods bearing the signature public OMElement
<method-name>(OMElement) where the method name can be anything
If we add an output message to the operation, then everything works
perfectly (but the operation isn't oneway any more):
<wsdl:portType name="SimplePortType">
<wsdl:operation name="SimpleOperation">
<wsdl:input message="tns:SimpleMessage"/>
<wsdl:output message="tns:SimpleMessage"/>
</wsdl:operation>
</wsdl:portType>
I also tried to manually change Message Receiver generated, so it extended
"AbstractInMessageReceiver". But I culdn't come to a valid solution.
Am I doing something wrong? Or is this a bug of Axis2-0.94? May I log a bug
in Jira?
Thank you in advance,
Rubén
Re: [Axis2-0.94] WSDL2Java generates bad code for complex types
Posted by Ajith Ranabahu <aj...@gmail.com>.
Hi Chuck,
Oops a daisy, We've significantly changed the de-serializing code and
the de-ser code is not simple anymore (the previous de-ser code was
buggy anyway). I'm in the process of fixing it further but right now
it handles only sequences. I'll incorporate the changes needed for the
choice and all soon.
Thanks for the fix anyway.
On 2/9/06, Chuck Williams <ch...@manawiz.com> wrote:
> Ajith,
>
> Thre was another problem in the patch I submitted to handle <choice>: the
> generated adb bean parse() methods used an incorrect value for the
> argumentCount. They assumed all arguments were required, rather than
> precisely 1. Fixing this required one more simple change to
> ADBBeanTemplate.xsl. The updated version of the complete patch (relative to
> 0.94 release) is attached.
>
> Chuck
>
>
>
> Chuck Williams <ch...@manawiz.com> wrote on 01/26/2006 08:23:24 AM:
>
>
>
> Hi Ajith
>
> I think the validation is a good idea, but the issues I listed below all
> generated NullPointerException's on valid wsdl. I have been validating the
> wsdl with my ide (Netbeans) prior to submitting it to the code generator.
> That did help to diagnose some problems, but not all. The code generator
> has many constraints that go beyond validation (e.g., names in many places
> they are not required due to the way the data structures work, valid
> references of course, and one I don't understand yet: messages with
> multiple parts are only supported if the part constraints are type=, not if
> they are element=).
>
> Thanks,
>
> Chuck
>
>
>
> Ajith Ranabahu <aj...@gmail.com> wrote on 01/26/2006 03:13:00 AM:
>
>
> Hi Chuck,
> Thanks for pointing out the issues.
> Yes, the code generator being non-validating is the problem here. We do
> not check whether the WSDL is valid before attempting to generate code. IMHO
> I think we should have a WOM validator as one of the extensions in the
> codegenerator - the user can switch off validation if needed.
> My guess is if we have the WSDL validator then we may overcome a number of
> issues
>
>
> On 1/26/06, Chuck Williams < chuck@manawiz.com> wrote:
> > Ajith,
> >
> > You probably already saw the second issue in the xsl (an unintended side
> effect on optional and array-valued properties). Just in case you didn't
> notice
> > that one, please see the difference in the new version of the patch (still
> against 0.94). I've now created and generated code for a large wsdl and so
> have growing confidence in the patch.
> >
> > The biggest issue I've seen in using the code generator is the lack of
> error detection. E.g., missing name attributes where axis2 expects them
> (even if
> > they are not required by the wsdl spec), multiple parts in messages that
> take elements rather than types (element= as opposed to type=), typos in
> certain references, all generally yield NullPointerException. With a large
> wsdl especially, the problems can be a challenge to find. Are there plans
> > to beef up the error checking?
> >
> > Thanks,
> >
> > Chuck
> >
> >
> >
> > Chuck Williams <ch...@manawiz.com> wrote on 01/24/2006 09:17:14 PM:
> >
> >
> >
> > Ajith, thanks again! Very nice of you to not embarass me on the list,
> although I managed to do that myself pretty well. :-)
> >
> > For the benefit of others using 0.94, the corrected patch is attached to
> this message. I also updated the bean schema for completeness, although it
> appears it is missing a couple other attributes as well so probably not
> important.
> >
> > Chuck
> >
> >
> >
> > Ajith Ranabahu <aj...@gmail.com> wrote on 01/24/2006 09:04:56 PM:
> >
> >
> > Well Actualy when I went through the patch I figured out the mistake:)
> It's already corrected :)
> >
> >
> > On 1/25/06, Chuck Williams < chuck@manawiz.com> wrote:
> > > Thanks Ajith! Unfortunately, I need to send you a revised version.
> There is a stupid mistake in my xsl that broke the other types! I had only
> verified that the <choice> code worked, not yet verified that the rest of
> the generated code wasn't affected. It's a trivial change I'm testing now,
> so should be just few. Mea culpa -- sorry for the confusion.
> > >
> > > Regarding the code, it is very easy to read. I compliment you on the
> organizaiton.
> > >
> > > Chuck
> > >
> > >
> > >
> > > Ajith Ranabahu <aj...@gmail.com> wrote on 01/24/2006 08:52:44
> PM:
> > >
> > >
> > >
> > > Hi Chuck,
> > > I looked at your solution and it is reasonable for handling choice. I
> applied the patch (Actually modified the classes looking at the patch.
> TortoiseSVN throws an exception when I try to apply the given patch)
> > > Thanks a lot for your effort in participating in the development effort.
> We really appreciate you coming forward and solving this issue. I've already
> solved the ref issue.
> > >
> > > BTW you seem to have understood the workings of the code well. Did it
> take a lot of effort to figure out the stuff ?
> > >
> > >
> > >
> > > On 1/25/06, Chuck Williams <chuck@manawiz.com > wrote:
> > > > Dims and Ajith,
> > > >
> > > > I took Dims' advice and created the attached patch to
> modules/codegen/src of Axis2 0.94. This may not be the best implementation
> of <choice> but it is very simple and meets my use cases. The idea is this.
> A <choice> is treated just like an <all> where each enclosed element has
> minOccurs=0, except that in the generated code setting any constituent
> element automatically unsets all the others. Thus, whatever choice you set
> last is the choice you get and you only get one. (The code does not enforce
> what happens if you don't set any; this, additional error checking, and
> accessors to fully determine the state of what has been chosen, could all be
> improved.)
> > > >
> > > > I'm just starting to work with it so have not tested it much yet, but
> the generated code looks right to me. It's very simple because it reuses
> all the code that is already there and makes just a few mods.
> > > >
> > > > I haven't tried complex nesting cases to see if they all work, and
> probably wont' because I only need <choice> of <element>'s, although in
> principle any nesting that <all> handles, choice should too.
> > > >
> > > > I noticed in doing this that none of the particles handle the <element
> ref=...> construction. This is somewhat painful, but livable. If I had
> more time, I'd try to fix that. It looks like it might be more complex than
> this hack due to the way the names are used in the data structures.
> > > >
> > > > I'd appreciate if you guys would add this to axis2 so I don't have to
> patch future releases. If it is not deemed suitable, please let me know why
> as perhaps I could fix it, or just fix it!
> > > >
> > > > Thanks,
> > > >
> > > > Chuck
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Ajith Ranabahu
> > >
> >
> >
> >
> > --
> > Ajith Ranabahu
> >
> >
> >
>
>
>
> --
> Ajith Ranabahu
>
>
>
--
Ajith Ranabahu
Re: [Axis2-0.94] WSDL2Java generates bad code for complex types
Posted by Ajith Ranabahu <aj...@gmail.com>.
Hi Chuck,
Thanks for pointing out the issues.
Yes, the code generator being non-validating is the problem here. We do not
check whether the WSDL is valid before attempting to generate code. IMHO I
think we should have a WOM validator as one of the extensions in the
codegenerator - the user can switch off validation if needed.
My guess is if we have the WSDL validator then we may overcome a number of
issues
On 1/26/06, Chuck Williams <ch...@manawiz.com> wrote:
>
> Ajith,
>
> You probably already saw the second issue in the xsl (an unintended side
> effect on optional and array-valued properties). Just in case you didn't
> notice
> that one, please see the difference in the new version of the patch (still
> against 0.94). I've now created and generated code for a large wsdl and
> so have growing confidence in the patch.
>
> The biggest issue I've seen in using the code generator is the lack of
> error detection. E.g., missing name attributes where axis2 expects them
> (even if
> they are not required by the wsdl spec), multiple parts in messages that
> take elements rather than types (element= as opposed to type=), typos in
> certain references, all generally yield NullPointerException. With a large
> wsdl especially, the problems can be a challenge to find. Are there plans
> to beef up the error checking?
>
> Thanks,
>
> Chuck
>
>
> Chuck Williams <ch...@manawiz.com> <ch...@manawiz.com> wrote on 01/24/2006
> 09:17:14 PM:
>
> Ajith, thanks again! Very nice of you to not embarass me on the list,
> although I managed to do that myself pretty well. :-)
>
> For the benefit of others using 0.94, the corrected patch is attached to
> this message. I also updated the bean schema for completeness, although it
> appears it is missing a couple other attributes as well so probably not
> important.
>
> Chuck
>
>
> Ajith Ranabahu <aj...@gmail.com> <aj...@gmail.com> wrote
> on 01/24/2006 09:04:56 PM:
>
> Well Actualy when I went through the patch I figured out the mistake:)
> It's already corrected :)
>
> On 1/25/06, Chuck Williams < chuck@manawiz.com> wrote:
> >
> > Thanks Ajith! Unfortunately, I need to send you a revised version.
> > There is a stupid mistake in my xsl that broke the other types! I had only
> > verified that the <choice> code worked, not yet verified that the rest of
> > the generated code wasn't affected. It's a trivial change I'm testing now,
> > so should be just few. Mea culpa -- sorry for the confusion.
> >
> > Regarding the code, it is very easy to read. I compliment you on the
> > organizaiton.
> >
> > Chuck
> >
> >
> > Ajith Ranabahu <aj...@gmail.com> <aj...@gmail.com>wrote on 01/24/2006
> > 08:52:44 PM:
> >
> > Hi Chuck,
> > I looked at your solution and it is reasonable for handling choice. I
> > applied the patch (Actually modified the classes looking at the patch.
> > TortoiseSVN throws an exception when I try to apply the given patch)
> > Thanks a lot for your effort in participating in the development effort.
> > We really appreciate you coming forward and solving this issue. I've already
> > solved the ref issue.
> >
> > BTW you seem to have understood the workings of the code well. Did it
> > take a lot of effort to figure out the stuff ?
> >
> >
> > On 1/25/06, Chuck Williams <chuck@manawiz.com > wrote:
> > >
> > > Dims and Ajith,
> > >
> > > I took Dims' advice and created the attached patch to
> > > modules/codegen/src of Axis2 0.94. This may not be the best
> > > implementation of <choice> but it is very simple and meets my use cases.
> > > The idea is this. A <choice> is treated just like an <all> where each
> > > enclosed element has minOccurs=0, except that in the generated code setting
> > > any constituent element automatically unsets all the others. Thus, whatever
> > > choice you set last is the choice you get and you only get one. (The code
> > > does not enforce what happens if you don't set any; this, additional error
> > > checking, and accessors to fully determine the state of what has been
> > > chosen, could all be improved.)
> > >
> > > I'm just starting to work with it so have not tested it much yet, but
> > > the generated code looks right to me. It's very simple because it reuses
> > > all the code that is already there and makes just a few mods.
> > >
> > > I haven't tried complex nesting cases to see if they all work, and
> > > probably wont' because I only need <choice> of <element>'s, although in
> > > principle any nesting that <all> handles, choice should too.
> > >
> > > I noticed in doing this that none of the particles handle the <element
> > > ref=...> construction. This is somewhat painful, but livable. If I had
> > > more time, I'd try to fix that. It looks like it might be more complex than
> > > this hack due to the way the names are used in the data structures.
> > >
> > > I'd appreciate if you guys would add this to axis2 so I don't have to
> > > patch future releases. If it is not deemed suitable, please let me know why
> > > as perhaps I could fix it, or just fix it!
> > >
> > > Thanks,
> > >
> > > Chuck
> > >
> > >
> > >
> > >
> > > <http://wso2.com/blogs/>
> > >
> > >
> > >
> > >
> >
> >
> > --
> > Ajith Ranabahu
> >
> >
> >
>
>
> --
> Ajith Ranabahu
>
>
>
>
>
--
Ajith Ranabahu
Re: [Axis2-0.94] WSDL2Java generates bad code for complex types
Posted by Davanum Srinivas <da...@gmail.com>.
Chuck,
Yes, error detection is a problem. We can do with *ALL* the help we
can get :) Am really happy to see your growing confidence :) Keep 'em
patches coming. Please log them in JIRA instead of email
(http://issues.apache.org/jira)
thanks,
dims
On 1/26/06, Chuck Williams <ch...@manawiz.com> wrote:
> Ajith,
>
> You probably already saw the second issue in the xsl (an unintended side
> effect on optional and array-valued properties). Just in case you didn't
> notice
> that one, please see the difference in the new version of the patch (still
> against 0.94). I've now created and generated code for a large wsdl and so
> have growing confidence in the patch.
>
> The biggest issue I've seen in using the code generator is the lack of
> error detection. E.g., missing name attributes where axis2 expects them
> (even if
> they are not required by the wsdl spec), multiple parts in messages that
> take elements rather than types (element= as opposed to type=), typos in
> certain references, all generally yield NullPointerException. With a large
> wsdl especially, the problems can be a challenge to find. Are there plans
> to beef up the error checking?
>
> Thanks,
>
> Chuck
>
>
>
> Chuck Williams <ch...@manawiz.com> wrote on 01/24/2006 09:17:14 PM:
>
>
>
> Ajith, thanks again! Very nice of you to not embarass me on the list,
> although I managed to do that myself pretty well. :-)
>
> For the benefit of others using 0.94, the corrected patch is attached to
> this message. I also updated the bean schema for completeness, although it
> appears it is missing a couple other attributes as well so probably not
> important.
>
> Chuck
>
>
>
> Ajith Ranabahu <aj...@gmail.com> wrote on 01/24/2006 09:04:56 PM:
>
>
> Well Actualy when I went through the patch I figured out the mistake:) It's
> already corrected :)
>
>
> On 1/25/06, Chuck Williams < chuck@manawiz.com> wrote:
> > Thanks Ajith! Unfortunately, I need to send you a revised version. There
> is a stupid mistake in my xsl that broke the other types! I had only
> verified that the <choice> code worked, not yet verified that the rest of
> the generated code wasn't affected. It's a trivial change I'm testing now,
> so should be just few. Mea culpa -- sorry for the confusion.
> >
> > Regarding the code, it is very easy to read. I compliment you on the
> organizaiton.
> >
> > Chuck
> >
> >
> >
> > Ajith Ranabahu <aj...@gmail.com> wrote on 01/24/2006 08:52:44 PM:
> >
> >
> >
> > Hi Chuck,
> > I looked at your solution and it is reasonable for handling choice. I
> applied the patch (Actually modified the classes looking at the patch.
> TortoiseSVN throws an exception when I try to apply the given patch)
> > Thanks a lot for your effort in participating in the development effort.
> We really appreciate you coming forward and solving this issue. I've already
> solved the ref issue.
> >
> > BTW you seem to have understood the workings of the code well. Did it take
> a lot of effort to figure out the stuff ?
> >
> >
> >
> > On 1/25/06, Chuck Williams <chuck@manawiz.com > wrote:
> > > Dims and Ajith,
> > >
> > > I took Dims' advice and created the attached patch to
> modules/codegen/src of Axis2 0.94. This may not be the best implementation
> of <choice> but it is very simple and meets my use cases. The idea is this.
> A <choice> is treated just like an <all> where each enclosed element has
> minOccurs=0, except that in the generated code setting any constituent
> element automatically unsets all the others. Thus, whatever choice you set
> last is the choice you get and you only get one. (The code does not enforce
> what happens if you don't set any; this, additional error checking, and
> accessors to fully determine the state of what has been chosen, could all be
> improved.)
> > >
> > > I'm just starting to work with it so have not tested it much yet, but
> the generated code looks right to me. It's very simple because it reuses
> all the code that is already there and makes just a few mods.
> > >
> > > I haven't tried complex nesting cases to see if they all work, and
> probably wont' because I only need <choice> of <element>'s, although in
> principle any nesting that <all> handles, choice should too.
> > >
> > > I noticed in doing this that none of the particles handle the <element
> ref=...> construction. This is somewhat painful, but livable. If I had
> more time, I'd try to fix that. It looks like it might be more complex than
> this hack due to the way the names are used in the data structures.
> > >
> > > I'd appreciate if you guys would add this to axis2 so I don't have to
> patch future releases. If it is not deemed suitable, please let me know why
> as perhaps I could fix it, or just fix it!
> > >
> > > Thanks,
> > >
> > > Chuck
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> > --
> > Ajith Ranabahu
> >
>
>
>
> --
> Ajith Ranabahu
>
>
>
--
Davanum Srinivas : http://wso2.com/blogs/
Re: [Axis2-0.94] WSDL2Java generates bad code for complex types
Posted by Ajith Ranabahu <aj...@gmail.com>.
Well Actualy when I went through the patch I figured out the mistake:) It's
already corrected :)
On 1/25/06, Chuck Williams <ch...@manawiz.com> wrote:
>
> Thanks Ajith! Unfortunately, I need to send you a revised version. There
> is a stupid mistake in my xsl that broke the other types! I had only
> verified that the <choice> code worked, not yet verified that the rest of
> the generated code wasn't affected. It's a trivial change I'm testing now,
> so should be just few. Mea culpa -- sorry for the confusion.
>
> Regarding the code, it is very easy to read. I compliment you on the
> organizaiton.
>
> Chuck
>
>
> Ajith Ranabahu <aj...@gmail.com> <aj...@gmail.com> wrote
> on 01/24/2006 08:52:44 PM:
>
> Hi Chuck,
> I looked at your solution and it is reasonable for handling choice. I
> applied the patch (Actually modified the classes looking at the patch.
> TortoiseSVN throws an exception when I try to apply the given patch)
> Thanks a lot for your effort in participating in the development effort.
> We really appreciate you coming forward and solving this issue. I've already
> solved the ref issue.
>
> BTW you seem to have understood the workings of the code well. Did it take
> a lot of effort to figure out the stuff ?
>
>
> On 1/25/06, Chuck Williams <ch...@manawiz.com> wrote:
> >
> > Dims and Ajith,
> >
> > I took Dims' advice and created the attached patch to
> > modules/codegen/src of Axis2 0.94. This may not be the best
> > implementation of <choice> but it is very simple and meets my use cases.
> > The idea is this. A <choice> is treated just like an <all> where each
> > enclosed element has minOccurs=0, except that in the generated code setting
> > any constituent element automatically unsets all the others. Thus, whatever
> > choice you set last is the choice you get and you only get one. (The code
> > does not enforce what happens if you don't set any; this, additional error
> > checking, and accessors to fully determine the state of what has been
> > chosen, could all be improved.)
> >
> > I'm just starting to work with it so have not tested it much yet, but
> > the generated code looks right to me. It's very simple because it reuses
> > all the code that is already there and makes just a few mods.
> >
> > I haven't tried complex nesting cases to see if they all work, and
> > probably wont' because I only need <choice> of <element>'s, although in
> > principle any nesting that <all> handles, choice should too.
> >
> > I noticed in doing this that none of the particles handle the <element
> > ref=...> construction. This is somewhat painful, but livable. If I had
> > more time, I'd try to fix that. It looks like it might be more complex than
> > this hack due to the way the names are used in the data structures.
> >
> > I'd appreciate if you guys would add this to axis2 so I don't have to
> > patch future releases. If it is not deemed suitable, please let me know why
> > as perhaps I could fix it, or just fix it!
> >
> > Thanks,
> >
> > Chuck
> >
> >
> >
> >
> > <http://wso2.com/blogs/>
> >
> >
> >
> >
>
>
> --
> Ajith Ranabahu
>
>
>
--
Ajith Ranabahu
Re: [Axis2-0.94] WSDL2Java generates bad code for complex types
Posted by Ajith Ranabahu <aj...@gmail.com>.
Hi Chuck,
I looked at your solution and it is reasonable for handling choice. I
applied the patch (Actually modified the classes looking at the patch.
TortoiseSVN throws an exception when I try to apply the given patch)
Thanks a lot for your effort in participating in the development effort. We
really appreciate you coming forward and solving this issue. I've already
solved the ref issue.
BTW you seem to have understood the workings of the code well. Did it take a
lot of effort to figure out the stuff ?
On 1/25/06, Chuck Williams <ch...@manawiz.com> wrote:
>
> Dims and Ajith,
>
> I took Dims' advice and created the attached patch to modules/codegen/src
> of Axis2 0.94. This may not be the best implementation of <choice> but it
> is very simple and meets my use cases. The idea is this. A <choice> is
> treated just like an <all> where each enclosed element has minOccurs=0,
> except that in the generated code setting any constituent element
> automatically unsets all the others. Thus, whatever choice you set last is
> the choice you get and you only get one. (The code does not enforce what
> happens if you don't set any; this, additional error checking, and accessors
> to fully determine the state of what has been chosen, could all be
> improved.)
>
> I'm just starting to work with it so have not tested it much yet, but the
> generated code looks right to me. It's very simple because it reuses all
> the code that is already there and makes just a few mods.
>
> I haven't tried complex nesting cases to see if they all work, and
> probably wont' because I only need <choice> of <element>'s, although in
> principle any nesting that <all> handles, choice should too.
>
> I noticed in doing this that none of the particles handle the <element
> ref=...> construction. This is somewhat painful, but livable. If I had
> more time, I'd try to fix that. It looks like it might be more complex than
> this hack due to the way the names are used in the data structures.
>
> I'd appreciate if you guys would add this to axis2 so I don't have to
> patch future releases. If it is not deemed suitable, please let me know why
> as perhaps I could fix it, or just fix it!
>
> Thanks,
>
> Chuck
>
>
>
> <http://wso2.com/blogs/>
>
>
>
>
--
Ajith Ranabahu
Re: [Axis2-0.94] WSDL2Java generates bad code for complex types
Posted by Davanum Srinivas <da...@gmail.com>.
OR help implement choice in ADB :) i highly recommend that because
i've seen some perf issues with xmlbeans (check xmlbeans jira)
-- dims
On 1/24/06, Ajith Ranabahu <aj...@gmail.com> wrote:
> Hi Chuck,
> The choice element is not handled in the ADB schema compiler yet (at least
> we are not sure what is the best way to deal with it). Right now we do not
> throw any exceptions but silently skip that (that is why the empty class)
> Please use XMLBeans if you need the support for choice for now.
>
>
> On 1/24/06, Chuck Williams <ch...@manawiz.com> wrote:
> > I have a complexType that contains a <choice> of two alternative
> > elements, like this:
> >
> > <xsd:complexType name="AorB">
> > <xsd:choice>
> > <xsd:element name="A" type="xsd:string"/>
> > <xsd:element name="B" type="xsd:string"/>
> > </xsd:choice>
> > </xsd:complexType>
> >
> > and a reponse message that contains a value of this type:
> >
> > <message name="respmessage">
> > <part name="resp" type="asxsd:AorB"/>
> > </message>
> >
> > and a portType with an operation that returns the response message:
> >
> > <portType name="FooPortType">
> > <operation name="Bar">
> > <input .../>
> > <output message="as:respmessage"/>
> > </operation>
> > </portType>
> >
> > WSDL2Java generates a class AorB and requires it as content of the
> > respmessage to be returned from the Bar() method in the generated
> > FooPortTypeSkeleton. However, AorB has no setters or getters, so there
> > is no way to give it the A or B element to return. Also, A and B do not
> > extend AorB so there is no way to pass either of them directly.
> >
> > How is this supposed to work?
> >
> > Thanks for any help,
> >
> > Chuck
> >
> >
>
>
>
> --
> Ajith Ranabahu
--
Davanum Srinivas : http://wso2.com/blogs/
Re: [Axis2-0.94] WSDL2Java generates bad code for complex types
Posted by Ajith Ranabahu <aj...@gmail.com>.
Hi Chuck,
Interesting approach :) Although the hardcore web service people might argue
that it is not a good pattern to follow ;)
> Does axis2 with XMLBeans also provide the capability to directly access
> StAX to custom-parse incoming message parameters ?
Yep. All XMLBeans objects have a method to access the pullparser (although
I'm not sure about the internal implementation). have a look at the
generated toOM methods after codegenerating for XMLBeans.
--
Ajith Ranabahu
Re: [Axis2-0.94] WSDL2Java generates bad code for complex types
Posted by Ajith Ranabahu <aj...@gmail.com>.
Hi Chuck,
The choice element is not handled in the ADB schema compiler yet (at least
we are not sure what is the best way to deal with it). Right now we do not
throw any exceptions but silently skip that (that is why the empty class)
Please use XMLBeans if you need the support for choice for now.
On 1/24/06, Chuck Williams <ch...@manawiz.com> wrote:
>
> I have a complexType that contains a <choice> of two alternative
> elements, like this:
>
> <xsd:complexType name="AorB">
> <xsd:choice>
> <xsd:element name="A" type="xsd:string"/>
> <xsd:element name="B" type="xsd:string"/>
> </xsd:choice>
> </xsd:complexType>
>
> and a reponse message that contains a value of this type:
>
> <message name="respmessage">
> <part name="resp" type="asxsd:AorB"/>
> </message>
>
> and a portType with an operation that returns the response message:
>
> <portType name="FooPortType">
> <operation name="Bar">
> <input .../>
> <output message="as:respmessage"/>
> </operation>
> </portType>
>
> WSDL2Java generates a class AorB and requires it as content of the
> respmessage to be returned from the Bar() method in the generated
> FooPortTypeSkeleton. However, AorB has no setters or getters, so there
> is no way to give it the A or B element to return. Also, A and B do not
> extend AorB so there is no way to pass either of them directly.
>
> How is this supposed to work?
>
> Thanks for any help,
>
> Chuck
>
>
--
Ajith Ranabahu