axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Schoeman <>
Subject Re: At my wits end - Axis2 and abstract types...
Date Sat, 25 Feb 2006 15:44:52 GMT
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...




PS - Managed to convert types by XMLBeans, but still cannot retrieve the 
type information...

EANDeviceID gid =

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

View raw message