users@jersey.java.net

Re: [Jersey] File uploads through Jesery

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Fri, 22 Aug 2008 09:13:26 +0200

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