Rodrigo Ruiz wrote:
I use Axis 1.3, and it generates a different set of classes. I am not getting any class called "DeviceIDImpl", but an abstract "DeviceID" one. I think the difference comes from Axis2 XmlBeans support (I see you activate this option in the command-line). Have you inspected the source code of "DeviceIDImpl"? For what you said, it seems that it has the appropriate data, at least internally, despite its class name. If that class is a "bag" for several WSDL types, it might have methods for converting from and to the "supported" subtypes. This is just a guess, because I don't know how XmlBeans work. :-P
I borrowed some class inspection code, and recursed up the entire object hierarchy without finding any obvious methods/properties...
I am at work now, so I cannot expend much time in testing the generated classes, but I will try later ;-)
Thanks - any chance if you can see if you can convice Axis1.3 to serialise the abstract classes? 1.3 looks a lot better all-round (except for this problem).
Apart from this, I see another error in the msgId field. Its datetime attribute is filled with the result of calling toString() on a Calendar instance, and this is incorrect. In the client code, you should do something like:
Hmmm... The autogenerated bean asks for a java.util.Calendar object... Thanks for all the help! -justin
