You are viewing a plain text version of this content. The canonical link for it is here.

Posted to users@cxf.apache.org by Deepak Agrawal <de...@adobe.com> on 2015/02/28 07:50:23 UTC

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 :

 public interface FirstVersionResult {



   public boolean isSuccess();

   public String getErrorMessage();

   public ResultCode getErrorCode();

   public AccessToken getAccessToken();

 }


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

 public interface 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>

     <property name="errorCode" ignore="true"/>

     <property name="errorCodev2" mappedName="errorCode"/>

     <property name=“accessToken" ignore="true"/>

     <property name="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.95B372388A64@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

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

Posted by Deepak Agrawal <de...@adobe.com>.

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: "users@cxf.apache.org<ma...@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.95B372388A64@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