On Wed July 29 2009 5:30:13 am dp-isp wrote: > Sorry if my question is trivial... in order to test your fixes, can I > download the latest snapshot > (http://repository.apache.org/snapshots/org/apache/cxf/apache-cxf/2.2.3-SNA >PSHOT/) or there is a better way?
Yea. But testing out the actual 2.2.3 release candidate that we are voting on would be good as well: https://repository.apache.org/content/repositories/cxf-staging-003/org/apache/cxf/apache-cxf/2.2.3 Dan > Thanks, > Marco > > dkulp wrote: > > Well, I THOUGHT this would have been easily doable, but when I checked, > > it turns out the attachments were not streaming properly in MTOM mode. > > :-( > > > > I've gone through and fixed a BUNCH of things related to the attachment > > handling and streaming and such so some of this is now possible. > > > > Now, with the latest code, when you get the DataSource, if at all > > possible, > > the input stream that is returned will properly be streaming off the wire > > instead of cached. Thus, you can copy directly from there to the output > > stream. > > > > There are cases where this WON'T work stream directly, notably when > > schema validation is turned on. In that case, to work around issues in > > JAXB, we buffer the content. Also, if there are multiple attachments, > > only the last > > one can really be streamed this way. The others get buffered. > > > > Dan > > > > On Mon July 27 2009 5:50:00 am dp-isp wrote: > >> Hello everybody, > >> > >> We have a CXF webservice that is a kind of "repository service" and a > >> webapp working as frontend for that repository. > >> Those two components are on separate hosts. > >> > >> We would need to realize a continuous stream of data when downloading > >> attachments from CXF webservice to the users' browser through the > >> frontend > >> webapp. > >> > >> The webapp is basically a servlet that invokes the webservice, receives > >> the > >> attachment datahandler and copies datahandler InputStream to servlet > >> response OutputStream (servlet code is at the end of this email). > >> > >> Our issue: is it possible to directly link datahandler InputStream to > >> servlet response OutputStream without re-building the whole attachment > >> in memoroy or in a temporary file? (as can be configured by setting > >> org.apache.cxf.io.CachedOutputStream.Threshold, > >> org.apache.cxf.io.CachedOutputStream.OutputDirectory) > >> > >> Going more into details, is there a way to send to CXF the output buffer > >> to > >> write the attachment on? In such case we would send to CXF the sevlet's > >> output buffer. > >> > >> Alternatively, is there a way to manage CXF working asynchronously with > >> attachments, giving back control to the servlet before attachment > >> downolad > >> completion? > >> > >> Many thanks, > >> Marco > >> > >> --- > >> > >> This is the servlet's involved code: > >> > >> ... > >> StreamingService_Service ss = new StreamingService_Service(new > >> URL(serviceURL)); > >> StreamingService port = ss.getServiceImplPort(new MTOMFeature()); > >> > >> Resume myFile = port.downloadMethod(fileName, fileType, usr, pwd, repo); > >> DataHandler handler = myFile.getResume(); > >> > >> response.setHeader("Pragma", "No-cache"); > >> response.setContentType("application/octet-stream"); > >> response.setHeader("content-disposition", "attachment; filename=" + > >> fileName + "." + fileType); > >> try { > >> InputStream is = handler.getInputStream(); > >> try { > >> OutputStream os = response.getOutputStream(); > >> try { > >> byte[] b = new byte[100000]; > >> int bytesRead = 0; > >> while ((bytesRead = is.read(b)) != -1) { > >> os.write(b, 0, bytesRead); > >> } > >> System.out.println("Download del file " + > >> myFile.getCandidateName() + > >> "." + myFile.getResumeFileType() + " completato."); > >> } finally { > >> os.flush(); > >> os.close(); > >> } > >> } finally { > >> is.close(); > >> } > >> > >> } catch (Exception e) { > >> e.printStackTrace(); > >> } > >> ... > > > > -- > > Daniel Kulp > > [email protected] > > http://www.dankulp.com/blog -- Daniel Kulp [email protected] http://www.dankulp.com/blog
