1

We have an application currently running on WAS8. Now we migrate this application to Liberty. Currently we have the problem that the SOAP responses of this application are of content type multipart/related. Looking like that:

HTTP/1.1 200 OK
X-Powered-By: Servlet/3.1
Content-Type: multipart/related; type="application/soap+xml"; boundary="uuid:acacdbe0-a9a8-46cc-aedf-58570a630ff7"; start="<root.message@cxf.apache.org>"; start-info="application/soap+xml"
Content-Language: en-DE
Content-Length: 670
Date: Thu, 28 Sep 2017 12:00:16 GMT


--uuid:acacdbe0-a9a8-46cc-aedf-58570a630ff7
Content-Type: text/xml; charset=UTF-8; type="application/soap+xml";
Content-Transfer-Encoding: binary
Content-ID: <root.message@cxf.apache.org>

<soap:Envelope>....</soap:Envelope>
--uuid:acacdbe0-a9a8-46cc-aedf-58570a630ff7--

This is bad for us, because other clients might run into parsing problems.

With WAS8 the response is of content type application/soap+xml;charset=UTF-8;action="mySoapResponse" and without the uuid and stuff.

Here I found something similar to my problem, but not quite. We, too, have SOAPBinding defined, but as annotation at my @WebService looking like that: @SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE) or @BindingType(value = javax.xml.ws.soap.SOAPBinding.SOAP12HTTP_BINDING)

To make the application work on Liberty, we had to update the deployment descriptor (web.xml) from version 2.4 to 3.0. I guess this also changed the behaviour of the application.

Is the main cause really because of the SOAPBinding annotation or could it be something else?

UPDATE: Here is the response of the WAS8 application server for comparison:

HTTP/1.1 200 OK
Date: Wed, 04 Oct 2017 06:24:22 GMT
Cache-Control: private
Cache-Control: max-age=10
X-Frame-Options: SAMEORIGIN
X-Powered-By: Servlet/3.0
Content-Length: 403
Keep-Alive: timeout=20
Connection: Keep-Alive
Content-Type: application/soap+xml; charset=UTF-8; action="mySoapResponse"
Content-Language: en-US

<?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope ...>...</soapenv:Envelope>

UPDATE2:

I noticed that the Liberty SOAP response also gets an <env:header> that is not in the WAS8 response

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
    <env:Header xmlns:env="http://www.w3.org/2003/05/soap-envelope"/>
    <soap:Body>...

So there seems to be something that is going on in the background. I looked into the WSDL, but there is no header defined nor some multipart. How can I trace back the steps and see where this setting is made to my response?

kinglite
  • 339
  • 3
  • 20

2 Answers2

0

Maybe Liberty is using MTOM automatically. If you see <xop:Include.. in the SOAP envelope, it's probably MTOM. You might be able to turn it off by adding an annotation to the WebService, @MTOM(enabled="false")

Bruce T.
  • 992
  • 4
  • 5
  • I added this to my webservice, but it still responds the same way. But I also see no in my SOAP envelope, even without @MTOM used. So does this mean it's something else? – kinglite Oct 02 '17 at 13:49
0

According to the IBM support, this behaviour of CXF (Liberty) is due to the annotation @XmlAttachmentRef in one of my JAXB classes. Removing this would result in a non multipart response. Unfortunately, when I do so, attachments sent will not be processed correctly and the MIME type will be lost.

Currently we have IBM support looking into this, if this can be fixed somehow in CXF (Liberty), because in Axis2 (tWAS8.0) it behaved different. I will try to keep this updated.

kinglite
  • 339
  • 3
  • 20