[
https://issues.jboss.org/browse/JBWS-3593?page=com.atlassian.jira.plugin....
]
Alessio Soldano commented on JBWS-3593:
---------------------------------------
I did some investigation on this issue; basically, what happens is that if the MTOM
enabled endpoint has multiple operations, responses for any of them end up into
multipart/related messages regardless of an attachment being actually present or not.
Please note the messages (including the content type values) are still valid, it's
just that the message is a multipart one (actually with just a single part if there's
no attachment).
This behaviour is basically a consequence of the the @MTOM / @BindingType annotations
being type level ones and of the way Apache CXF integrates with JAXB (see
org.apache.cxf.jaxb.io.DataWriterImpl and
org.apache.cxf.jaxb.attachment.JAXBAttachmentMarshaller). To me the only way to change
this would be for Apache CXF to have a mechanism for automatically detecting if a given
message response would contain an attachment, so that the mtom-enabled prop could be set
to false in the current cxf Message. That would likely imply scanning the generated java
model for the endpoint and looking for @XmlMimeType annotations or similar approach. XFIRE
(which predates CXF) had a feature request jira for this need, see
http://jira.codehaus.org/browse/XFIRE-664, user might consider creating a new CXF jira for
this (it's an addition / new feature though, not really a bug).
As a temporary measure / workaround, the user can add a simple out interceptor to his
endpoint, which can explicitly disable MTOM depending on the selected operation. I've
added a testcase to the JBossWS testsuite to demonstrate this [1][2]. The interceptor is
here [3].
[1]
http://anonsvn.jboss.org/repos/jbossws/stack/cxf/trunk/modules/testsuite/...
[2]
http://anonsvn.jboss.org/repos/jbossws/stack/cxf/trunk/modules/testsuite/...
(search '3593')
[3]
http://anonsvn.jboss.org/repos/jbossws/stack/cxf/trunk/modules/testsuite/...
multipart/related messages exchanged for @MTOM annotated endpoint
even if no attachment is included
---------------------------------------------------------------------------------------------------
Key: JBWS-3593
URL:
https://issues.jboss.org/browse/JBWS-3593
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: jbossws-cxf, jbossws-native
Affects Versions: jbossws-cxf-4.0.2, jbossws-native-4.0.2
Environment: Jboss AS 7.1.1Final
Reporter: A l e c C R E S T A N
Assignee: Alessio Soldano
Fix For: jbossws-cxf-4.2
On JBoss AS 7.1.1, with the following service implementation:
{code}
@WebService(...)
@javax.xml.ws.BindingType (value=javax.xml.ws.soap.SOAPBinding.SOAP12HTTP_MTOM_BINDING)
public class SEIImpl {
...
public DataHandler getBin() {...} /* maps to a type="xs:base64Binary" in wsdl
*/
public List<String> getString(){...} /* maps to sequence of String in wsdl */
...
}
{code}
With the default *jbossws-cxf*, the responses are:
- for getString() method
Content-Type: multipart/related; type="application/xop+xml"; ...
- for getBin() method
Content-Type: multipart/related; type="application/xop+xml"; ...
-> +both responses are MTOM/XOP modified ! The getString() response should not.+
With *jbossws-native* (after the jbossws stack switching) , the responses are the
expected ones:
- for getString() method
Content-Type: text/xml;charset=UTF-8 <env:Envelope .... text content
..../env:Envelope>
- for getBin() method
Content-Type: multipart/related; type="application/xop+xml"; ...
Best regards,
Note: same behaviour with @javax.xml.ws.soap.MTOM or SOAP11HTTP_MTOM_BINDING
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira