So here's something of interest - I think some of the behavior has to do with 
how the MTOM field is defined.  Most examples, including the one used by CXF 
have it as a field within a request object.  in my case, the SOAP service is 
exposing the MTOM attribute as a separate argument.  this is what my wsdl 
operation looks like

<wsdl:operation name="createContent">
            <soap:operation 
soapAction="http://www.supercompany.com/content/creation/2/createContent"/>
            <wsdl:input>
                <mime:multipartRelated>
                    <mime:part name="request">
                        <soap:body parts="request" use="literal"/>
                    </mime:part>
                    <mime:part name="attachment">
                        <mime:content part="attachment" type="*/*"/>
                    </mime:part>
                </mime:multipartRelated>
            </wsdl:input>
            <wsdl:output>
                <soap:body use="literal"/>
            </wsdl:output>
        </wsdl:operation>

Note that I added the xmime attribute to see if that helped with the processing 
but didn't.

Now that I can grab the raw data, basically what we're seeing is the generated 
SOAP call

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";>
        <soap:Header>
                <wsse:Security 
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";
 
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
 soap:mustUnderstand="1">
                        <wsse:UsernameToken /> <!-- skipped for brevity -->
                </wsse:Security>
        </soap:Header>
        <soap:Body>
                <ns3:createContentRequest 
xmlns="http://www.supercompany.com/content/creation/bi/2/"; 
xmlns:ns2="http://www.supercompany.com/content/2/"; 
xmlns:ns3="http://www.supercompany.com/content/creation/2/"; 
xmlns:ns4="http://www.supercompany.com/common/status/1/";>
                        <createContentRequest /> <!-- skipped -->
                </ns3:createContentRequest>
                <ns3:attachment 
xmlns="http://www.supercompany.com/content/creation/bi/2/"; 
xmlns:ns2="http://www.supercompany.com/content/2/"; 
xmlns:ns3="http://www.supercompany.com/content/creation/2/"; 
xmlns:ns4="http://www.supercompany.com/common/status/1/";>
                        <xop:Include 
xmlns:xop="http://www.w3.org/2004/08/xop/include"; 
href="cid:b3f6177b-ec45-4bc6-8517-2f8651525cee-1@www.supercompany.com"/>
                </ns3:attachment>
        </soap:Body>
</soap:Envelope>

Has the section starting with <ns3:attachment> which no one is expecting and 
that seems to be the issue, instead the raw content should just be parsed from 
the body of the message (which we can see is coming correctly).

Thanks,

John

On 2019/03/29 18:37:38, "John D. Ament" <johndam...@apache.org> wrote: 
> Hi,
> 
> I'm looking to integrate with an existing webservice that uses attachments
> for its handling of binary content.  I've enabled mtom on my client.  I've
> tested the service using SoapUI and I can see that it properly handles the
> attachment when using the attachment option in SoapUI.
> 
> When I try to replicate this request in CXF, it fails.  But I notice the
> call CXF makes is vastly different than the one I see in SoapUI.  For
> instance, CXF adds the attachment object as an element in the SOAP call,
> but SoapUI does not.
> 
> The WSDL has 2 parts to it, one with the request xml and a second wsdl:part
> with name attachment and type xs:base64Binary.  I can see the mime related
> parts for the attachment object being set to application/octet-stream.
> 
> I'm wondering if there's something special I have to do to enable this
> service to work from the client perspective?
> 
> Thanks,
> 
> John
> 

Reply via email to