Yeah -- there were lots of bugs in 1.0. The developers are aiming to release 1.1 at the end of September.
On 8/31/06, Doolittle, Todd <[EMAIL PROTECTED]> wrote:
Anne, I just pulled last night's build and tried it. It appears to work correctly. So somewhere between the last release and now it's been fixed. Any idea when the next release will happen? Thanks again! Todd -----Original Message----- From: Anne Thomas Manes [mailto:[EMAIL PROTECTED] Sent: Thursday, August 31, 2006 3:20 PM To: [email protected] Subject: Re: Databinding with WSDL2JAVA Please file a JIRA. Axis2 ADB should be able to deal with anonymous types. Meanwhile, you might try using XMLBeans in place of ADB. Anne On 8/31/06, Doolittle, Todd <[EMAIL PROTECTED]> wrote: > > Nirmit, > > Thanks for the fast reply! > > The "name" attribute is not allowed to appear in an "inline" complexType > element. > > I agree that the second form of the WSDL with the complex types > predefined is much better. The problem is I'm consuming someone else's > service, so I did not write the WSDL. Unfortunately they use this > "inlining" of complexTypes in all their WSDL, so as it stands, each time > they make a change or provide a new service, I must go through all the > WSDL by hand and pull out the complex types. Because these services are > much more complex than the example I provided this is both time > consuming and error prone. > > It does appear that Axis 1.4 handles it correctly, but I hate to write > new code using Axis 1.4 only to have to migrate it to Axis2 at a later > time. > > Thanks again! > Todd > > > -----Original Message----- > From: Nirmit Desai [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 31, 2006 12:54 PM > To: [email protected] > Subject: Re: Databinding with WSDL2JAVA > > it sounds like a bug... > > my guess is that as the outer complex tyoe is not given a name, it > simply > ignores it for databinding. Try giving a name o the outer complex type? > > I never tried defining types for elements inline. Having seprate type > definitions allows you to reuse the types for different elements too. > > -Nirmit > > > > > > "Doolittle, Todd" > > <[EMAIL PROTECTED] > > .com> > To > <[email protected]> > > 08/31/2006 12:13 > cc > PM > > > Subject > Databinding with WSDL2JAVA > > Please respond to > > [EMAIL PROTECTED] > > he.org > > > > > > > > > > > > > > > I'm using Axis2 to generate a client from WSDL. I'm having a problem > with > the databinding. The WSDL I'm using is somewhat complex, so to > illustrate > the problem I created some simpler WSDL. Consider this fictitious > service > that takes as a request a last name, and then returns as a response the > husband (first name, last name) and wife (first name, last name, maiden > name) registered with that last name. > > > Here are how the types are defined in the WSDL: > > > <xsd:schema targetNamespace="http://www.example.org/family2/";> > > > <xsd:element name="FamilyLookupRequest"> > > > <xsd:complexType> > > > <xsd:sequence> > > > <xsd:element name="lastName" type="xsd:string" /> > > > </xsd:sequence> > > > </xsd:complexType> > > > </xsd:element> > > > <xsd:element name="FamilyLookupResponse"> > > > <xsd:complexType> > > > <xsd:sequence> > > > <xsd:element name="husband"> > > > <xsd:complexType> > > > <xsd:sequence> > > > <xsd:element name="firstName" type="xsd:string" /> > > > <xsd:element name="lastName" type="xsd:string" /> > > > </xsd:sequence> > > > </xsd:complexType> > > > </xsd:element> > > > <xsd:element name="wife"> > > > <xsd:complexType> > > > <xsd:sequence> > > > <xsd:element name="firstName" type="xsd:string" /> > > > <xsd:element name="lastName" type="xsd:string" /> > > > <xsd:element name="maidenName" type="xsd:string" /> > > > </xsd:sequence> > > > </xsd:complexType> > > > </xsd:element> > > > </xsd:sequence> > > > </xsd:complexType> > > > </xsd:element> > > > </xsd:schema> > > > In Axis2 it doesn't handle this correctly. The FamilyLookupRequest > object > is created correctly. But because the FamilyLookupResponse has nested > complex types Axis2 does not create the FamilyLookupResponse class > correctly. Axis2 creates the husband_type0 and wife_type1 classes > correctly. The FamilyLookupResponse class contains a husband and wife > member, but they are defined as OMElements instead of their correct type > (husband_type1, and wife_type0). > > > If I change the WSDL as follows, Axis2 will then create the classes > correctly. Any ideas? Is this a bug? > > > <xsd:schema targetNamespace="http://www.example.org/family2/";> > > > <xsd:complexType name="husband"> > > > <xsd:sequence> > > > <xsd:element name="firstName" type="xsd:string" /> > > > <xsd:element name="lastName" type="xsd:string" /> > > > </xsd:sequence> > > > </xsd:complexType> > > > <xsd:complexType name="wife"> > > > <xsd:sequence> > > > <xsd:element name="firstName" type="xsd:string" /> > > > <xsd:element name="lastName" type="xsd:string" /> > > > <xsd:element name="maidenName" type="xsd:string" /> > > > </xsd:sequence> > > > </xsd:complexType> > > > <xsd:element name="FamilyLookupRequest"> > > > <xsd:complexType> > > > <xsd:sequence> > > > <xsd:element name="lastName" type="xsd:string" /> > > > </xsd:sequence> > > > </xsd:complexType> > > > </xsd:element> > > > <xsd:element name="FamilyLookupResponse"> > > > <xsd:complexType> > > > <xsd:sequence> > > > <xsd:element name="husband" type="fml:husband" /> > > > <xsd:element name="wife" type="fml:wife" /> > > > </xsd:sequence> > > > </xsd:complexType> > > > </xsd:element> > > > </xsd:schema> > > > > > > Lastly Axis 1.4 handles either version of the WSDL correctly. > > > > > > This message, including any attachments, is the property of Sears > Holdings > Corporation and/or one of its subsidiaries. It is confidential and may > contain proprietary or legally privileged information. If you are not > the > intended recipient, please delete it without reading the contents. Thank > you. > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
