[
https://issues.apache.org/jira/browse/CXF-3870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13131727#comment-13131727
]
Benson Margulies commented on CXF-3870:
---------------------------------------
If you could take the time to create a small example of the phenomenon that
would be helpful; otherwise one of us will have to do that.
> aegis databing SOAP response does not respect validation standard
> ------------------------------------------------------------------
>
> Key: CXF-3870
> URL: https://issues.apache.org/jira/browse/CXF-3870
> Project: CXF
> Issue Type: Bug
> Components: Aegis Databinding
> Affects Versions: 2.4.3
> Environment: Debian/Tomcat/Spring/CXF/Aegis/Hibernate/PostgreSQL
> Reporter: alexandre collier
>
> 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:
> {quote}
> AbstractObjectA implements-> InterfaceObjectA
> ObjectAImpl extends-> AbstractObjectA
> AbstractObjectB implements-> InterfaceObjectB
> AbstractObjectB extends-> AbstractObjectA
> ObjectBImpl extends-> AbstractObjectB
> {quote}
> Spring and aegis configuration:
> {quote}
> <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>
> {quote}
> here is the wsdl:types part of resulting wsdl :
> {quote}
> <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>
> {quote}
> Here is a web service declaration:
> {quote}
> @WebMethod
> public ObjectB methodWithB(@WebParam(name = "pInputTypeB", mode =
> WebParam.Mode.IN) ObjectB pInputTypeB)
> {quote}
> and the soap response to a call to that service:
> {quote}
> <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>
> {quote}
> 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
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
