wso2 cpp code generation with wsdl2cpp client side with MTOM attachment - soap

Question

I have a soap web service exposed with axis2 (Java) which serializes POJOs, such as a Person that has a name and so on, as action responses. Moreover, I have an action which uses a DataHandler that is serialized in order to put a binary attachment in the response using <xop:Include ...></xop:Include>
I have generated the client side code in c++ using wsdl2cpp provided by wso2 wsfcpp. The getPerson(personId) action works fine and the results are as expected. However, the getFile(someId) action is successful although the generated code doesn't seem to work properly.
The service as enableMTOM=true set in axis2.xml as well as the client. I even added the Options.setEnableMTOM(true) to be sure in the main on the client side.
I believe that the problem is the code that is generated from the wsdl since the envelope of the getFile(someId) response is valid (and I have tested it manually with the axis2c api and I can retrieve the file as expected).
Here is the schema contained in the wsdl (which is generated from axis2 Java) for the response:
<xs:element name="getFileResponse">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0" name="return" nillable="true" type="xs:base64Binary"/>
</xs:sequence>
</xs:complexType>
</xs:element>
Here is the command line used to generate the client code:
WSDL2CPP -uri MyService.xml -g -d adb -u -f
Here is the response received from the service:
<ns:getFileResponse xmlns:ns="http://services.myplace.com">
<ns:return>
<xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include" href="cid:1.3ad8fc0571509f196559ee5312c14d23250854e4c9c8383e#apache.org"></xop:Include>
</ns:return>
</ns:getFileResponse>
Is there something missing in the wsdl or is that feature (soap with MTOM client code generation) not implemented by wsfcpp?
Thanks in advance!

Answer 1

I've tried the same thing with gSoap and I had the same problem. I figured that axis2 automatically detect whether the binary is optimized or not. Also, I found that in either case, the return element type exposed by the wsdl is type="xs:base64Binary".
The only work around I found was to patch, by replacing xs:base64Binary by xop:Include, the WSDL using a python (or whatever) script and then generate the code.
That solved the problem but makes maintainability issues.