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.Sandoz_at_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 <Ashishr_at_coreobjects.com>
> To: "users_at_jersey.dev.java.net" <users_at_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.Sandoz_at_Sun.COM]
> Sent: Thursday, August 21, 2008 1:03 PM
> To: users_at_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.
>
>
>
>
>