Hello,
I'm having a problem getting a service to return an Mtom attachment. CXF
2.1.3, inside Tomcat.
My service was previously working correctly using CXF 2.0.4 inside the Mule
ESB.
Interface method:
DataHandler downloadAttached(String authToken, int fileId) ;
Implemention:
public DataHandler downloadAttached(String authToken, int fileId) throws
ServiceException{
IFileObj fileObj = getFileObject(fileId);
File f = new File(uploadDocumentFolder + "/" +
fileObj.getFilename());
if (!f.exists()){
throw new ServiceException //---- snip
}
DataSource source = new FileDataSource(uploadDocumentFolder + "/" +
fileObj.getFilename());
DataHandler dh = new DataHandler(source);
return dh;
}
(uploadDocumentFolder is just a string, the path)
The returned soap envelope contains:
<ns1:return>
<ns2:Include
href="cid:12308936361890-730252543@http://www.w3.org/2001/XMLSchema"
xmlns:ns2="http://www.w3.org/2004/08/xop/include"/>
</ns1:return
But the actual attachment is missing. (I have checked the raw data too).
Tested with SoapUI and a Jaxws client.
with 2.0.4, the same fragment - with attachment present - was:
<ns1:return ns2:mimeType="application/octet-stream"
xmlns:ns2="http://www.w3.org/2004/11/xmlmime">
<ns3:Include
href="cid:12306362745010155464574@http://www.w3.org/2001/XMLSchema"
xmlns:ns3="http://www.w3.org/2004/08/xop/include"/>
</ns1:return>
The mimeType is missing as you can see with 2.1.3 but this may just be a
symptom of the missing attachment? I have never specified mimeType anywhere
in the code or config.
I have checked the FileDataSource, and the DataHandler, on the service side,
reading their streams, and each seems to be present ok and returns the
correct file size after reading. So I don't believe it's a problem with the
service itself.
Mtom is definitely enabled successfully on the service, because other
methods are receiving MTOM attachments from the client, and those all work
fine.
Relevant snippet from the generated wsdl:
<xsd:element name="downloadAttachedResponse"
type="tns:downloadAttachedResponse" />
<xsd:complexType name="downloadAttachedResponse">
<xsd:sequence>
<xsd:element minOccurs="0" name="return" type="xsd:base64Binary" />
</xsd:sequence>
The service itself is using Aegis binding, spring configs as follows:
<bean id="aegisBean"
class="org.apache.cxf.aegis.databinding.AegisDatabinding"
scope="prototype">
<property name="configuration">
<bean class="org.apache.cxf.aegis.type.TypeCreationOptions">
<property name="defaultMinOccurs" value="1"/>
<property name="defaultNillable" value="false"/>
</bean>
</property>
</bean>
<bean id="aegisBeanMtom" parent="aegisBean" scope="prototype">
<property name="mtomEnabled" value="true" />
</bean>
<bean id="jaxws-and-aegis-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.aegis.databinding.AegisServiceConfiguration"/>
<bean
class="org.apache.cxf.service.factory.DefaultServiceConfiguration"/>
</list>
</property>
</bean>
<bean id="jaxws-and-aegis-service-factory-mtom"
parent="jaxws-and-aegis-service-factory" scope="prototype">
<property name="dataBinding" ref="aegisBeanMtom" />
</bean>
(beans are split up like that because other services don't require Mtom)
<jaxws:endpoint id="fileUpload"
implementorClass="test.IUploadService"
name="fileUpload"
implementor="#uploadService"
serviceName="s:fileUpload"
address="/services/fileUpload"
xmlns:s="http://test.services">
<jaxws:serviceFactory>
<ref bean="jaxws-and-aegis-service-factory-mtom"/>
</jaxws:serviceFactory>
</jaxws:endpoint>
I have tried moving the DataHandler inside a wrapper bean, and having the
method return that, didn't have any effect. I understand there are
limitations to Aegis (e.g. inability to set mimeType) but it was all working
correctly with 2.0.4 so I can't understand what could have changed.
--
View this message in context:
http://www.nabble.com/MTOM-return-attachment---empty-tp21250413p21250413.html
Sent from the cxf-user mailing list archive at Nabble.com.