cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Deepak Agrawal <deagr...@adobe.com>
Subject FW: Interface polymorphism breaks Aegis Binding mapping of response interfaces in Versioned SOAP API
Date Fri, 20 Mar 2015 05:13:39 GMT
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<mailto:users@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
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message