FW: Interface polymorphism breaks Aegis Binding mapping of response interfaces in Versioned SOAP API

[Deepak Agrawal]

Hi All,

Could someone please help us on the below mentioned issue and provide a 
solution?
Our migration from Xfire to CXF is stuck due to this reason which means we 
can’t get any of security updates.

Thanks,
Deepak

From: deagrawa
Date: Saturday, February 28, 2015 at 12:20 PM
To: "us...@cxf.apache.org<mailto:us...@cxf.apache.org>"
Subject: Interface polymorphism breaks Aegis Binding mapping of response 
interfaces in Versioned SOAP API

Hi,

We are migrating our SOAP services from Xfire(1.2.6 , using 
ObjectServiceFactory) with Aegis Binding to latest CXF(3.0.3, using simple 
frontend) with Aegis Binding.
We were able to get the service up and running with latest CXF with Aegis 
Binding but it broke our versioning system and changed the response of 
versioned APIs as a result.

With Aegis Binding, we define the interfaces of response and an aegis mapping 
file corresponding to that interface. Hence, we have different interfaces of 
same response for different versions but only one implementation class for 
response.
For example,
  First version interface response is as follows :

 publicinterface FirstVersionResult {



   publicboolean isSuccess();

   public String getErrorMessage();

   public ResultCode getErrorCode();

   public AccessToken getAccessToken();

 }


  Then, our second version response with different parameters would be :

 publicinterface SecondVersionResult extends FirstVersionResult {



   public ResultCode getErrorCodev2();

   public AccessToken getAccessTokenv2();

 }

  As second version response should not contain errorCode and accessToken, as 
mentioned in FirstVersionResult Interface, aegis mapping file corresponding to 
SecondVersionResult would ignore errorCode and accessToken such as :

 <mappings>

   <mapping>

     <propertyname="errorCode"ignore="true"/>

     <propertyname="errorCodev2"mappedName="errorCode"/>

     <propertyname=“accessToken"ignore="true"/>

     <propertyname="accessTokenv2"mappedName="accessToken"/>

   </mapping>

 </mappings>


The above mentioned way of versioning used to work fine in Xfire but not in CXF 
: Xfire used to ignore errorCode and accessToken for SecondVersion API call but 
CXF includes errorCode and accessToken as well in the Second Version API 
response XML.

By comparing the code of Xfire and CXF, we figured out that while creating the 
response XML, CXF gets the superInterfaces as well while Xfire used to check 
only for superClasses. Hence, CXF then maps all the elements of super 
Interfaces in response XML as well.


The change to check for super Interfaces in CXF is made against 
CXF-3870<https://issues.apache.org/jira/browse/CXF-3870> to support interface 
polymorphism.

Specific change in BeanType.getSuperType() which broke Xfire’s versioning 
system is as follows( as given here mentioning all CXF-3870 
changes<http://mail-archives.apache.org/mod_mbox/cxf-commits/201110.mbox/%3c20111025203012.95b372388...@eris.apache.org%3E>)
 :

+Class c = inf.getTypeClass();

+        if (c.isInterface() && c.getInterfaces().length == 1) {
+            c = c.getInterfaces()[0];
+        } else {
+            c = c.getSuperclass();
+        }


Could you please let us know if we could be missing some other configuration 
which will stop this from happening ?

As interface polymorphism seems to be deliberately not supported in Xfire, will 
this be taken up as a bug ?


Any help would be very much appreciated.


Thanks,

Deepak