| From | Sent On | Attachments |
|---|---|---|
| Kevin Duffey | Aug 20, 2008 8:20 pm | |
| Paul Sandoz | Aug 21, 2008 12:33 am | |
| Ashish Raniwala | Aug 21, 2008 4:28 pm | |
| Kevin Duffey | Aug 21, 2008 11:55 pm | |
| Paul Sandoz | Aug 22, 2008 12:05 am | |
| Paul Sandoz | Aug 22, 2008 12:13 am | |
| Ryan Heaton | Aug 22, 2008 12:51 pm | |
| Paul Sandoz | Aug 22, 2008 12:58 pm | |
| Ashish Raniwala | Aug 22, 2008 1:15 pm | |
| Paul Sandoz | Aug 22, 2008 1:22 pm |
| Subject: | Re: [Jersey] File uploads through Jesery | |
|---|---|---|
| From: | Paul Sandoz (Paul...@Sun.COM) | |
| Date: | Aug 22, 2008 12:58:26 pm | |
| List: | net.java.dev.jersey.users | |
Very neat!
Paul.
On Aug 22, 2008, at 9:51 PM, Ryan Heaton wrote:
If I may add a suggestion, you could also just have jersey supply the HttpServletRequest (assuming you're deploying in a ServletContainer) and parse it using commons fileupload. It even provides a streaming API for large files, etc.
E.g.
@POST public void upload(@Context HttpServletRequest request, @PathParam fileName, ...) throws Exception { if (ServletFileUpload.isMultipartContent(request)) { // Create a factory for disk-based file items FileItemFactory factory = new DiskFileItemFactory();
// Create a new file upload handler ServletFileUpload upload = new ServletFileUpload(factory);
// Parse the request List /* FileItem */ items = upload.parseRequest(request); } }
-Ryan
On Fri, Aug 22, 2008 at 1:13 AM, Paul Sandoz <Paul...@sun.com> wrote:
Hi Kevin, If your files are very very large then i think you will have to be careful using MIME multipart implementations because they may buffer content. If you want to experiment use the JavaMail API and the type javax.mail.internet.MimeMultipart. JAX-RS providers support for reading/writing this. The closest example i can point you to using the JavaMail API is in the unit tests :-( see the following class: com.sun.jersey.impl.entity.EntityTypesTest and the method: testMimeMultipartRepresentation Paul. On Aug 22, 2008, at 8:56 AM, Kevin Duffey wrote:
Something a fellow coworker (or two) suggested is what I think Paul was referring to, where somehow we post a multi-part content-type where by the first part is xml that describes the file, size, maybe anything else to go with it to be part of the specific api call, and then the rest of the file is the binary image itself. My coworker suggested the same thing, that the mail.jar library could probably handle the binary file part of it, where as the REST service could handle the initial xml that was the first part of the message. What I am not sure on at this point is how to go about this, haven't yet started looking into it. But I think this is what we both need Ashish. If anybody else on the list has already done something like this, it would be greatly appreciated to share the code and/or some info on how you did it. Otherwise, I am game for working with anyone else on not only making this work, but providing it as perhaps a "demo" app to Jersey on how to do such a thing. I am guessing more people than just us will want/ need this capability.
----- Original Message ---- From: Ashish Raniwala <Ashi...@coreobjects.com> To: "use...@jersey.dev.java.net" <use...@jersey.dev.java.net> Sent: Thursday, August 21, 2008 4:28:33 PM Subject: RE: [Jersey] File uploads through Jesery
Hi Paul,
I am new user of JERSEY. What you explained here is exactly what I am looking for. I need to support very large file uploads. Is there any code/example you can refer me to?
My requirement is to support concurrent partial file uploads and file size can be as large as 10 GB.
Thanks, Ashish
From: Paul Sandoz [mailto:Paul...@Sun.COM] Sent: Thursday, August 21, 2008 1:03 PM To: use...@jersey.dev.java.net Subject: Re: [Jersey] File uploads through Jesery
Hi Kevin,
I would avoid embedding large binary files in XML as it either requires them to be base 64 encoded or using some like MTOM which IMHO is not really designed to be consumed directly (because to do so breaks the layering of the XML infoset).
One solution is to explicitly use MIME multipart (using say multipart/form-data or multipart/mixed). The first body part can be the XML data and the second body part can be the binary file. This is much more explicit that in the MTOM case and i think is much easier for clients to produce/consume. You can use the JavaMail API for this, although there is experimental support for "multipart/form-data" when using @FormParam. We need to improve this area to make it easier and also improve the streaming for certain cases.
Another solution is to make the resources for the binary file separate from the meta-data. I think this is especially useful for large files and if you want to manipulate the meta-data separate from the file itself. It also means it is possible to support ETag/Last-Modified on the XML and binary data separately and enable partial GETs of large files.
Combining the above it is possible to POST a MIME multipart message to a resource from which it creates two separate resources, one for the XML and one for the binary file. This makes it easier to get the XML data separately from the binary file. A slightly different variant (one that AtomPub specifies) is to POST the binary file from which some default XML for the XML resource is created and then can be modified (in AtomPub this is how you can create media-based Atom entries).
Another variant is to POST some XML data from which a ticket URI is created from which to upload the binary file. if the client does not upload the file within a certain period the ticket expires and the "transaction" does not complete.
There are many ways :-) all much better IMHO than embedding binary data in XML documents.
You can use InputStream as a type for parameters or a return type of a resource method. You can also use the File type (when used for consuming a temporary file will be created, when used for producing this is efficient as it streams the contents of the file).
Hope this helps, Paul.
On Aug 21, 2008, at 5:20 AM, Kevin Duffey wrote:
I am curious if there is anyone on the list who has dealt with file uploads via a REST call. My project will have this need sooner than later and rather than try to reinvent the wheel, if anyone has already done this, and wouldn't mind posting there code/thoughts on this subject, I'd appreciate it very much. Primarily how do we attach a binary/text file to an xml body as part of a request, then parse it on the other side.
Thanks.





