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.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.
>>
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>