WS-Security: possible bug with MTOM

[kosulin]

Hi, I use MTOM to send zip archive with WS response, and it works like a charm. However, when I add support for WS-Security, all web methods which send plain XML response, succeed, but the method which responds with ZIP file attached using MTOM, I get an Exception:

14:59:47,457 ERROR [SOAPFaultHelperJAXWS] SOAP request exception
org.jboss.ws.WSException: No ByteArrayConverter for content type: application/zip
 at org.jboss.ws.core.utils.MimeUtils.getConverterForContentType(MimeUtils.java:217)
 at org.jboss.ws.extensions.xop.XOPContext.replaceBase64Representation(XOPContext.java:290)
 at org.jboss.ws.extensions.xop.XOPContext.restoreXOPDataDOM(XOPContext.java:266)
 at org.jboss.ws.extensions.xop.XOPContext.restoreXOPDataDOM(XOPContext.java:275)
 at org.jboss.ws.extensions.xop.XOPContext.restoreXOPDataDOM(XOPContext.java:275)
 at org.jboss.ws.extensions.xop.XOPContext.restoreXOPDataDOM(XOPContext.java:275)
 at org.jboss.ws.core.soap.SOAPContentElement.handleMTOMTransitions(SOAPContentElement.java:600)
 at org.jboss.ws.extensions.xop.RestoreXOPElementVisitor.visitSOAPContentElement(RestoreXOPElementVisitor.java:73)
 at org.jboss.ws.core.soap.SOAPContentElement.accept(SOAPContentElement.java:611)
 at org.jboss.ws.extensions.xop.RestoreXOPElementVisitor.visitXOPElements(RestoreXOPElementVisitor.java:54)
 at org.jboss.ws.extensions.xop.RestoreXOPElementVisitor.visitXOPElements(RestoreXOPElementVisitor.java:63)
 at org.jboss.ws.extensions.xop.XOPContext.visitAndRestoreXOPData(XOPContext.java:246)
 at org.jboss.ws.core.jaxws.handler.HandlerDelegateJAXWS.callResponseHandlerChain(HandlerDelegateJAXWS.java:109)
 at org.jboss.ws.core.server.ServiceEndpointInvoker.callResponseHandlerChain(ServiceEndpointInvoker.java:132)
 at org.jboss.ws.core.server.ServiceEndpointInvoker.invoke(ServiceEndpointInvoker.java:267)
 at org.jboss.wsf.stack.jbws.RequestHandlerImpl.processRequest(RequestHandlerImpl.java:466)
 at org.jboss.wsf.stack.jbws.RequestHandlerImpl.handleRequest(RequestHandlerImpl.java:284)
 at org.jboss.wsf.stack.jbws.RequestHandlerImpl.doPost(RequestHandlerImpl.java:201)
 at org.jboss.wsf.stack.jbws.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:134)
 at org.jboss.wsf.stack.jbws.EndpointServlet.service(EndpointServlet.java:84)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
 at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:183)
 at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:189)
 at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)
 at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:90)
 at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:96)
 at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
 at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
 at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
 at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
 at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:325)
 at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:828)
 at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
 at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
 at java.lang.Thread.run(Unknown Source)

application/zip is a standard MIME-type. Is this a bug or my fault?

[kosulin]

Sorry, here is my config: jre 1.6.0_07, JBoss 5.0.0CR1, jbossws-3.0.2.

[karypid]

Just an idea: try using application/octet-stream.

Not sure it would help though...

[kosulin]

The issue with application/octet stream is in how out client handles response. Clients (java and .NET) invoke a proper plug-in based on the MIME type, and we need to support at least 3 various MIME-types (ZIP, exe, pdf). We can make workaround by analyzing the file extension, but the main question is: is this the bug (both WS-Security and MTOM work great separately), or am I doing something wrong?