Accidentally discovered the root cause of the problem... Still not sure
how to fix it though.
It seems that Axis2 has some trouble parsing input that is 'Web Services
Addressing' encoded. Discovered that by accident when I was trying to
debug the problem, but had a wsa->xsi filter in line to allow MS clients
to connect.
So, is there any way to switch Axis2 Web Services Addressing off?
Firstly, this would make it easier to connect to dotNET clients, and
secondly, it would fix the abstract types problem...
?
Thanks,
Justin
PS - Managed to convert types by XMLBeans, but still cannot retrieve the
type information...
EANDeviceID gid =
(EANDeviceID)EANDeviceID.Factory.parse(cid.toString());
Will convert abstract type cid to real implementation gid, but you need
to know the type of gid up front - cid.schemaType() is that of the
abstract type...
Justin Schoeman wrote:
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
