Hello,
I'm using MTOM attachments (with JAX-WS, not from schemas) following the
instructions found on
http://cxf.apache.org/docs/mtom-attachments-with-jaxb.html
The sample service is returning a Picture Object with a custom
DataSource as following:
@WebMethod(operationName = "GetPicture")
public Picture getPicture() {
Picture ret = new Picture();
DataSource source = new DataSource() {
@Override
public OutputStream getOutputStream() throws IOException {
return null;
}
@Override
public String getName() {
return null;
}
@Override
public InputStream getInputStream() throws IOException {
return new ByteArrayInputStream(new byte[] { 10, 20 });
}
@Override
public String getContentType() {
return "image/png";
}
};
ret.setImageData(new DataHandler(source));
return ret;
}
This is the actual message stream flowing from the server to the client:
HTTP/1.1 200 OK
Content-Type: multipart/related; type="application/xop+xml";
boundary="uuid:9ed9e39c-5cfa-4946-8b3a-085b3aa92f13";
start="<[email protected]>"; start-info="text/xml"
Content-Length: 810
Server: Jetty(6.1.21)
--uuid:9ed9e39c-5cfa-4946-8b3a-085b3aa92f13
Content-Type: application/xop+xml; charset=UTF-8; type="text/xml";
Content-Transfer-Encoding: binary
Content-ID: <[email protected]>
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><ns2:GetPictureResponse
xmlns:ns2="test"><return><title>title</title><imageData><xop:Include
xmlns:xop="http://www.w3.org/2004/08/xop/include"
href="cid:ccc0970b-980f-4bd0-bd90-5ffd4181a047-3@http%3A%2F%2Fcxf.apache.org%2F"/></imageData></return></ns2:GetPictureResponse></soap:Body></soap:Envelope>
--uuid:9ed9e39c-5cfa-4946-8b3a-085b3aa92f13
Content-Type: image/png
Content-Transfer-Encoding: binary
Content-ID: <ccc0970b-980f-4bd0-bd90-5ffd4181a04...@http://cxf.apache.org/>
.
--uuid:9ed9e39c-5cfa-4946-8b3a-085b3aa92f13--
On the client side I can access the ByteArrayDataSource of the picture
object. This has a correct input stream (as set in the service) but an
incorrect content type "application/octet-stream". Note that the sniffed
message contains the attachment with the correct content type "image/png".
This seems a bug IMHO, looking forward for your comments,
Enrico