Hi, 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 <rmigl...@quark.com> wrote: From: Rahul Miglani <rmigl...@quark.com> Subject: Problem with Polymorphic data types with ADB stubs on client side and RPC*MessageReceiver on Server side. To: axis-dev@ws.apache.org Date: Thursday, April 23, 2009, 9:50 AM Hi, 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 http://www.w3.org/2001/XMLSchema-instance 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 BeanUtil.java file. Also a new file has been added by name BeanClassMapper.java which expects a “Namespace2PackageMapping.properties” 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. Thanks and Regards, Rahul Miglani Quark Media House.
