Re: DataSource content-type using MTOM

[Enrico Boldrini]

Dear Daniel,

thanks for the quick response. I found out that actually I was not 
linking CXF dependencies on the client side.
In fact I was using: "JAX-WS RI 2.1.6 in JDK 6".
Updating the dependencies it works as expected, so, it definitely seems 
a bug of JAX-WS RI.

Thanks again,

Enrico


Daniel Kulp wrote:
That does sound like a bug.  Can you create a small test case and attach it to 
a JIRA?    I'm not sure what we can do about it though.   This may be in JAXB, 
but if we can get a test case in, we can dig in a bit more.

Dan

On Friday 05 March 2010 10:42:56 am Enrico Boldrini wrote:
  
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="<root.mess...@cxf.apache.org>"; 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: <root.mess...@cxf.apache.org>

<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";><soap:Body><ns2:GetP
ictureResponse
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.or
g%2F"/></imageData></return></ns2:GetPictureResponse></soap:Body></soap:Env
elope>

--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