Sudhir,
You don't have to do any special for parsing the complex data types in your WSDL. The xrpcc tool will generate for you Java code for your types, serializers for these new Java classes, code needed to register all that serializers, etc.
But there are some concerns which I'd lake to share with, because I do exactly the same - trying to generate Java client code from WSDL and ran across some limitations, where I have to adjust WSDL in order to get what I want to.
Some WSDL constructs are optional and no code will be generated for them, like: ref, union, choice, group, restrictions, etc. (refer to spec chapter 18 for details), also some XML types are not supported - just don't use them (see spec 4.2.1). Plus not everything may work as expected.
Unfortunately, I could not find a way of determining what actually is wrong in my WSDL, there is no log file for it. If some construct is not supported - just a smaller subset of generated files is produced and analyzing result is the only way for me to find the problem.
I also had to adjust generated <myService>_SerializerRegistry.java code, because my types were generated correctly, but registration of serialezers for some types in this class was missing. I had to do some other changes in generated code to make it work at runtime.
So you have to be carefull with WSDL, it may not work for the first time and may need adjustment, especially if you WSDL was not generated by tool.
I hope this will help you.
Thanks,
Michael
On Fri, 3 May 2002 16:19:18 -0700, Sudhir <sudhir_at_INFOLEAD.COM> wrote:
>Hi,
> I am trying to parse a given WSDL and generate the clients on the fly. I am
>able to do that for WSDL's with simple data types. I want to know how do I
>go about parsing the complex data types. Any help/suggestions/existing code
>samples would be very helpful to me.
>
>Thanks
>Sudhir
>
>----- Original Message -----
>From: "Sapozhnikov Michael" <msapozhnikov_at_AXSONE.COM>
>To: <JAXRPC-INTEREST_at_JAVA.SUN.COM>
>Sent: Friday, May 03, 2002 12:14 PM
>Subject: Extension of complex types
>
>
>> Hi,
>> I have problems with extesion of complex type:
>>
>> <complexType name="UserContextType">
>> <sequence>
>> <element name="SYS_USER" minOccurs="0" type="string"/>
>> <element name="GROUP_ID" minOccurs="0" type="string"/>
>> <element name="DBMAP" minOccurs="0" type="string"/>
>> <element name="ENTITY" type="string" minOccurs="0"/>
>> </sequence>
>> </complexType>
>>
>> <!-- this does not work -->
>> <complexType name="UserRequestType">
>> <complexContent>
>> <extension base="tns:UserContextType">
>> <sequence>
>> <element name="HOST_USER" type="string" minOccurs="0"/>
>> <element name="HOST_PWD" type="string" minOccurs="0"/>
>> </sequence>
>> </extension>
>> </complexContent>
>> </complexType>
>>
>> <!-- below works, but I need to reuse types -->
>>
>> <complexType name="UserRequestType">
>> <sequence>
>> <element name="SYS_USER" minOccurs="0" type="string"/>
>> <element name="GROUP_ID" minOccurs="0" type="string"/>
>> <element name="DBMAP" minOccurs="0" type="string"/>
>> <element name="ENTITY" type="string" minOccurs="0"/>
>> <element name="HOST_USER" type="string" minOccurs="0"/>
>> <element name="HOST_PWD" type="string" minOccurs="0"/>
>> </sequence>
>> </complexType>
>>
>> I read spec and it says (Appendix: XML Schema support) that derivation of
>complex Types by extension is required in JAX-RPC 1.0.
>> My example matches example provided for complex type "Address" and its
>extension "USAddress", but it does not work. Is something wrong in my code
>or this is just a bug in RI?
>>
>> BTW, example provided uses unsupported type: zip element in USAddress is
>defined as
>> <element name="zip" type="positiveInteger"/>
>> but positiveInteger is not a supported XML type.
>>
>> This brings me to another question:
>> How to use positiveInteger, NonNegativeInteger, etc if
>> derivation of new simple types by restriction of an existing simple type
>is optional and derivation of complex type from a simple type is also
>optional (and as a matter of fact they are not implemented in RI)?
>>
>> What is a suggested way of implementing these types, or we just have to
>avoid them until they will be implemented?
>>
>> Any help greatly appreciated.
>>
>> Thanks,
>> Michael
>>