Ommiting @XmlMimeType breaks DataHandler unmarshalling

[Tomas-Kraus]

I have a test client that sends WS attachment using DataHandler like this:

MTOMEndpoint mtomEndpoint = getEndpointPort(); DataHandler send = new DataHandler(new FileDataSource(PNG_FILE)); DHRequest request = new DHRequest(send); DHResponse response = mtomEndpoint.echoData(request); DataHandler recv = response.getDataHandler();

The server WS just sends back what it receives: byte[] echoFile = StreamUtils.readStream((InputStream)(request.getDataHandler().getContent())); DataHandler o = new DataHandler(new ByteArrayInputStream(echoFile), request.getDataHandler().getContentType()); return new DHResponse(o);

The issue is in DHRequest and DHResponse classes I use. They are simple classes: @XmlType(name = "dataRequest", namespace = "http://mycompany/xop/doclit") public class DHRequest { private DataHandler dataHandler; public DHRequest() { } public DHRequest(DataHandler dataHandler)

{ this.dataHandler = dataHandler; }

// @XmlMimeType("image/png") public DataHandler getDataHandler() { System.out.println(dataHandler.getContentType()); return dataHandler; }

public void setDataHandler(DataHandler dataHandler) { this.dataHandler = dataHandler; }

}

DHResponse is the same if you replace Reuest with Response.

Without setting the @XmlMimeType annotation everything works and the message on the server side looks like this:

... Base64 encoded data ... The DataHandler's content type on the client side (see the System.out.println) is image/png in the request and application/octet-stream in the response. On the server side it is application/octet-stream in both cases. No matter what I set in @XmlMimteType, it always broke. I tried application/octet-stream, text/plain and image/png. The thing is that whenever I set a mime type explicitly, the message stop being Base64 encoded. Instead it is a message with a binary attachment. The following is when DHResponse used application/octet-stream: ------=_Part_2_74198202.1277739135119 Content-Type: application/xop+xml; type="text/xml" Content-Transfer-Encoding: 8bit Content-ID: ------=_Part_2_74198202.1277739135119 Content-Type: application/octet-stream Content-Transfer-Encoding: binary Content-Id: ... binary scarp ... -----=_Part_2_74198202.1277739135119- #### Environment Operating System: All Platform: All #### Affected Versions [2.2]

[Tomas-Kraus]

• Issue Imported From: https://github.com/javaee/jaxb-v2/issues/766
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @glassfishrobot

[Tomas-Kraus]

@glassfishrobot Commented Reported by opalka@java.net

[Tomas-Kraus]

@glassfishrobot Commented opalka@java.net said: I spent some time to help you with this issue and here are my investigations:

Before starting please have a look to:

JAXB 2.2 javadoc for the following annotations:

• @javax.xml.bind.annotation.XmlMimeType
• @javax.xml.bind.annotation.XmlInlineBinaryData

JAX-WS 2.2 javadoc for the following annotations:

• @javax.xml.ws.BindingType
• @javax.xml.ws.soap.MTOM
• @javax.xml.ws.soap.MTOMFeature

The following objects can be sent as MTOM/XOP attachments:

• byte[]
• java.awt.Image
• javax.xml.transform.Source
• javax.activation.DataHandler

Enabling MTOM on JAX-WS endpoint can be achieved:

• either by declaring @MTOM
• or by declaring @BindingType(value = "http://schemas.xmlsoap.org/wsdl/soap/http?mtom=true")

Enabling MTOM on JAX-WS client can be achieved:

• either ((SOAPBinding)((BindingProvider)port).getBinding()).setMTOMEnabled(true) on already created proxy
• or service.getPort(MTOMEndpoint.class, new MTOMFeature(true)) for proxies being created

If you don't specify @XmlMimeType on getter or if you specify both @XmlMimeType and @XmlInlineBinaryData on getter the attachment object will always be inlined on the wire.

If you specify only @javax.xml.bind.annotation.XmlMimeType on getter the attachment object will always be sent as MIME attachment on the wire.

@XmlMimeType is used in JAXB schema generator and adds xmlmime:expectedContentTypes to WSDL. Here's example: — <?xml version="1.0" encoding="UTF-8"?> <definitions ...>

...

... —

Conclusion:

JAXB un/marshalling violates MTOM/XOP specifications and generates invalid MTOM/XOP messages. JAXB should generate in XML schema and process xmlmime:contentType attribute on XML elements wrapping binary data (regardless of the fact they are sent as inlined base64Binary or MIME attachments - see MTOM/XOP specifications).

Example of broken message being exchanged: —

RGF0YUhhbmRsZXJSb3VuZHRyaXA= — When attachment that is un/marshalled by JAXB runtime is inlined the content type information is always lost (see generated schema). When attachment that is un/marshalled by JAXB runtime was sent as MIME multipart the content type information is obtained from MIME header.

[Tomas-Kraus]

@glassfishrobot Commented snajper said: reassigning

[Tomas-Kraus]

@glassfishrobot Commented snajper said: will try to address for 2.2.2

[Tomas-Kraus]

@glassfishrobot Commented @pavelbucek said: metro2.1-waived

[Tomas-Kraus]

@glassfishrobot Commented Was assigned to snajper

[Tomas-Kraus]

@glassfishrobot Commented This issue was imported from java.net JIRA JAXB-766