Uploaded image for project: 'CXF'
  1. CXF
  2. CXF-3870

aegis databing SOAP response does not respect validation standard

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 2.4.3
    • Fix Version/s: 2.5
    • Component/s: Aegis Databinding
    • Labels:
      None
    • Environment:

      Debian/Tomcat/Spring/CXF/Aegis/Hibernate/PostgreSQL

    • Estimated Complexity:
      Unknown

      Description

      We are using aegis data binding to produce SOAP and wsdl content in front a web server. Integration with spring works great, and the services are consumable by both Java and PHP clients. But if I validate the SOAP response with a tool (such as SOAP UI), an error occurs on complex type binding involving an inheritance pattern.

      Complex inheritance scheme:

      AbstractObjectA implements-> InterfaceObjectA
      ObjectAImpl extends-> AbstractObjectA
      AbstractObjectB implements-> InterfaceObjectB
      AbstractObjectB extends-> AbstractObjectA
      ObjectBImpl extends-> AbstractObjectB

      Spring and aegis configuration:

      <bean id="aegisContext" class="org.apache.cxf.aegis.AegisContext">
      <property name="writeXsiTypes" value="true" />
      <property name="enableJDOMMappings" value="true" />
      <property name="mtomEnabled" value="true" />
      <property name="beanImplementationMap">
      <map>
      <entry key="my.company.domain.ObjectA" value="AbstractObjectA"/>
      <entry key="my.company.domain.ObjectB" value="AbstractObjectB"/>
      </map>
      </property>
      <property name="rootClassNames">
      <set>
      <value>my.company.domain.ObjectAImpl</value>
      <value>my.company.domain.ObjectBImpl</value>
      </set>
      </property>
      </bean>

      <bean id="aegisBean" class="org.apache.cxf.aegis.databinding.AegisDatabinding" scope="prototype">
      <property name="aegisContext" ref="aegisContext"/>
      </bean>

      <bean id="service-factory" class="org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean" scope="prototype">
      <property name="dataBinding" ref="aegisBean" />
      <property name="serviceConfigurations">
      <list>
      <bean class="org.apache.cxf.jaxws.support.JaxWsServiceConfiguration" />
      <bean class="org.apache.cxf.service.factory.DefaultServiceConfiguration" />
      </list>
      </property>
      </bean>

      <jaxws:endpoint id="SoapServiceTestJaxws" implementor="#testService" address="/serviceTestJaxws" >
      <jaxws:serviceFactory>
      <ref bean='service-factory' />
      </jaxws:serviceFactory>
      </jaxws:endpoint>

      here is the wsdl:types part of resulting wsdl :

      <wsdl:types>
      <xsd:schema attributeFormDefault="qualified" elementFormDefault="qualified" argetNamespace="http://domain.company.my">

      <xsd:complexType name="ObjectB">
      <xsd:sequence>
      <xsd:element minOccurs="0" name="attributeA" nillable="true" type="xsd:string"/>
      <xsd:element minOccurs="0" name="attributeB" nillable="true" type="xsd:string"/>
      <xsd:element minOccurs="0" name="id" type="xsd:long"/>
      </xsd:sequence>
      </xsd:complexType>

      <xsd:complexType name="ObjectBImpl">
      <xsd:complexContent>
      <xsd:extension base="tns:AbstractObjectB">
      <xsd:sequence/>
      </xsd:extension>
      </xsd:complexContent>
      </xsd:complexType>

      <xsd:complexType abstract="true" name="AbstractObjectB">
      <xsd:complexContent>
      <xsd:extension base="tns:AbstractObjectA">
      <xsd:sequence>
      <xsd:element minOccurs="0" name="attributeB" nillable="true" type="xsd:string"/>
      </xsd:sequence>
      </xsd:extension>
      </xsd:complexContent>
      </xsd:complexType>

      <xsd:complexType name="ObjectAImpl">
      <xsd:complexContent>
      <xsd:extension base="tns:AbstractObjectA">
      <xsd:sequence/>
      </xsd:extension>
      </xsd:complexContent>
      </xsd:complexType>

      <xsd:complexType name="ObjectA">
      <xsd:sequence>
      <xsd:element minOccurs="0" name="attributeA" nillable="true" type="xsd:string"/>
      <xsd:element minOccurs="0" name="id" type="xsd:long"/>
      </xsd:sequence>
      </xsd:complexType>

      <xsd:complexType abstract="true" name="AbstractObjectA">
      <xsd:sequence>
      <xsd:element minOccurs="0" name="attributeA" nillable="true" type="xsd:string"/>
      <xsd:element minOccurs="0" name="id" type="xsd:long"/>
      </xsd:sequence>
      </xsd:complexType>

      </xsd:schema>
      </wsdl:types>

      Here is a web service declaration:

      @WebMethod
      public ObjectB methodWithB(@WebParam(name = "pInputTypeB", mode = WebParam.Mode.IN) ObjectB pInputTypeB)

      and the soap response to a call to that service:

      <soap:Envelope>
      <soap:Body>
      <ns1:methodWithBResponse>
      <return xsi:type="ns2:ObjectBImpl">
      <ns2:attributeA>attributeAValue</ns2:attributeA>
      <ns2:id>0</ns2:id>
      <ns2:attributeB>attributeBValue</ns2:attributeB>
      </return>
      </ns1:methodWithBResponse>
      </soap:Body>
      </soap:Envelope>

      We can see in wsdl content that inheritance between interfaces and abstract objects are not described. The inheritance tree isn't complete and similar to what is coded in java. If a service return type is described with an interface and the real content is an implementation object, validation of soap response will fail. Java clients (cxf aegis client) seem to be smart enough to unmarshall that kind of inheritance tree, PHP clients need to declare a data type mapping to complete the inheritance tree, but .NET client are blocking on validation of the soap response as they fail to match interface and implementation types (As far as I know).

      Existing tickets on XFire's jira were pointing that problem, have they been fixed in CXF :
      http://jira.codehaus.org/browse/XFIRE-556
      http://jira.codehaus.org/browse/XFIRE-558

      I've upgraded the CXF lib on my project to the last stable version (2.4.3) but the problem remains.

      If someone want to test it, I can supply a full working project (~40Mb due to a messy lib dir).

      Alex

        Attachments

          Activity

            People

            • Assignee:
              dkulp Daniel Kulp
              Reporter:
              acollier alexandre collier
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: