On Monday 08 March 2010 5:44:43 am Enrico Boldrini wrote: > 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.
Cool. Thanks for the update! Dan > > 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="<[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:G > >> etP 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 -- Daniel Kulp [email protected] http://dankulp.com/blog
