axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From WJ Krpelan <>
Subject Re: Problem with Polymorphic data types with ADB stubs on client side and RPC*MessageReceiver on Server side.
Date Thu, 23 Apr 2009 09:25:41 GMT
it goes against the philosophy of web services to become dependent on java packages or .net
assemblies or whatever.
it is essential that a "classname" within a soap-message is NOT relied upon for communication
purposes to have a special meaning within a certain framework.
you would kill interoperability this way
Cheers, Wolfgang

--- On Thu, 4/23/09, Rahul Miglani <> wrote:

From: Rahul Miglani <>
Subject: Problem with Polymorphic data types with ADB stubs on client side and RPC*MessageReceiver
on Server side.
Date: Thursday, April 23, 2009, 9:50 AM




I have an existing spring framework based Java application
where-in the services were exposed as web services using Axis 1.3. Now we are
migrating the same to Axis2 1.4.1.  

I have used the RPC*MessageReceiver classes for my MEPs and instead
of service implementation class parameter “SeviceClass” I am using the
“ServiceObjectSupplier” and the “SpringBeanName”
parameters in the services.xml file to describe my service. 


On the client side I am using the ADB stubs. When I encounter
any polymorphic data here i.e. if the client is sending a polymorphic data type
as a parameter, the RPC*MessageReceiver class is not able to de-serialize the
exact derived object instead it creates an object of the base class, resulting
in data loss.  


Actually the problem comes in the BeanUtil class’s
deserailize() method. A fix is already mentioned there for issues AXIS2-2055
and AXIS2-1899 to support polymorphism in POJO approach. The code expects that
a “type” attribute should be mentioned with a value as the fully
qualified class name of the actual type object whereas if we are using ADB
stubs on the client side then the request XML contains the “type”
attribute with a namespace as
and the value as just the class name, the package name is not sent. So the code
mentioned here fails. 


I have added a workaround for the problem and am attaching
the file modified along with the mail. Changes are in the file.
Also a new file has been added by name which expects a “”
file in the classpath that contains the mapping between the fully qualified java
classes and the namespace qualified object name as is received in the SOAP
request. Example properties file is also attached. 


Please suggest if the code is correct or if there is some
other way of achieving the desired result.  


and Regards, 


Media House. 


View raw message