I am exposing a SOAP service using Tomcat, Apache CXF and Spring Boot. The web service has MTOM enabled and it works as expected when testing it from SOAP UI.
The problem is that when I try to get the message with MTOM disabled from SOAP UI, I still get the message with an XOP attachment. The options from SOAP UI that I use are: Enable MTOM: false; Force MTOM: false.
I have tried to set the Accept header on the request to application/xml instead of application/xop+xml, but I still get the same thing.
The only time when I get the Byte64 stream is when I test with a file which is smaller than the threshold that I've set:
@MTOM(enabled = true, threshold = 2048)
What I would need is MTOM to be optional when it is set to enabled and to depend on the request, not only on the threshold, could this be a problem with SOAP UI or does my current configuration ignore the request parameters?
I need this because some clients of the web service don't support MTOM.
Here is the object I return from the exposed method:
public class Document {
private DataHandler fileData;
public DataHandler getFileData() {
return fileData;
}
public void setFileData(DataHandler fileData) {
this.fileData = fileData;
}
}
You can't control from the client whether you want the server to respond with an xop attachment or without.
JAX-WS, and I think none of its implementations such as CXF for example, care about the Accept
header since it's not specified in the SOAP specifications that the server has to read if from the request, nor which value it should write on the response. So it makes no difference if you put application/xml
or text/xml
or any other.
If the server has MTOM enabled it must always (as long as it falls into the threshold range) send back a soap response using MTOM.
The options from SOAP UI that I use are: Enable MTOM: false; Force MTOM: false
These are options for the request message, so in case you are sending a file in your request it would be encoded as a base64 attachment, meaning you are just disabling MTOM for the request.
It's a bummer but basically you are just left with two options:
Modify the server and disable MTOM or try to do something with interceptors like reading a value from the request and enabling/disabling mtom programatically for that single message based on that value. It's like implementing yourself a mechanism to decide wether that client supports MTOM or not.
Modify the clients that don's support MTOM which probably you can't do if you are asking this question.