I took a look at Jersey's built-in integration for MimeMultipart (from
Javamail) and your implementation of jersey-multipart. I found the former
API to be messy, out-of-date and return incorrect values (for example,
BodyPart.getFilename() returns null even if Content-Disposition contains a
filename). Your API was better but:
1) Given:
Content-Disposition: form-data; name="files"
you'd expect an API call that returns a Map with two rows:
[Content-Disposition, form-data]
[name, files]
Unfortunately your API returns: Content-Disposition = [form-data;
name="files"] and expects me to parse it myself. Any chance you'll improve
upon this?
2) I took a quick glance at the implementations and I see some problematic
//FIXME comments, such as not being able to configure how big an attachment
may get before being dumped to disk, requiring explict calls to cleanup(),
etc.
Gili
Craig McClanahan wrote:
>
> Gili wrote:
>> Hi Craig,
>>
>> On the topic of jersey-multipart:
>>
>> 1) Is it really Jersey-specific or can it be used with any JAX-RS
>> implementation?
>>
> Currently, the only Jersey-specific dependencies are in the unit tests.
> In principle the runtime should only require the JAX-RS APIs, JavaMail,
> and JAF. But I haven't tested it with anything else.
>> 2) I'm curious whether you looked into using Apache Commons FileUpload
>> instead of Javamail under the hood. FileUpload's jar is only 50k and
>> deals
>> exclusively with parsing this kind of data, versus Javamail which is an
>> entire email client. It might also be more flexible, better integrated
>> than
>> JavaMail.
>>
>>
> I hadn't looked at Commons FileUpload, based on the (perhaps mistaken?)
> assumption that it only supported "multipart/form-data". I'll
> definitely go take a look.
>
> On the other hand, basically all the server side apps I'm working on are
> running on Glassfish anyway, so JavaMail comes integrated "for free" :-).
>> Gili
>>
>>
> Craig
>
>> Craig McClanahan wrote:
>>
>>> For those who don't know me, I have been around the Java web tier for
>>> quite a while, being the original author of the Struts framework
>>> (<http://struts.apache.org>), as well as co-spec-lead for JavaServer
>>> Faces 1.0 and 1.1. My more recent interests have focused on RESTful web
>>> services, which led me naturally towards JAX-RS and the Jersey
>>> implementation.
>>>
>>> I've been one of the folks inside Sun who has been leveraging Jersey for
>>> some internal projects over the last few months. We had a particular
>>> need to support MIME multipart/* media types, and it made sense to
>>> generalize this into a reusable module -- hence, I've just uploaded the
>>> "jersey-multipart" module to the "contribs" directory. It relies on 1.0
>>> or later Jersey code, and provides what I hope are found to be elegant
>>> solutions to the problems of multipart handling, while leveraging all
>>> the nice JAX-RS providers support for dealing with the entity content of
>>> body parts, just like we've grown spoiled by on complete message
>>> bodies. And, it works both on the server side and the client side, when
>>> you use jersey-client.
>>>
>>> Example server code to build a multipart response might look like this:
>>>
>>> // I have also provided an appropriate MessageBodyWriter for the
>>> MyBean class
>>> MyBean bean = ...;
>>> return Response.ok(new MultiPart().
>>> type(new MediaType("multipart", "mixed").
>>> bodyPart("This is the first body part in plain text", new
>>> MediaType("text", "plain")).
>>> bodyPart(bean, new MediaType("x-application",
>>> "x-format"))).build();
>>>
>>> (Of course, you can do things in a more fine-grained fashion, but the
>>> builder pattern utilized all over the JAX-RS and Jersey APIs was so cool
>>> that Paul suggested I use it here too, so I did :-).
>>>
>>> To read a MultiPart entity (produced by code like the previous example)
>>> that was uploaded to the server you might do something like this:
>>>
>>> // I have also provided an appropriate MessageBodyReader for the
>>> MyBean class
>>> @Path("...")
>>> @PUT
>>> @Consumes("multipart/mixed")
>>> @Produces(...)
>>> public Response handler(MultiPart multiPart) {
>>> BodyPart part0 = multiPart.getBodyParts().get(0);
>>> String text = part0.getEntityAs(String.class);
>>> BodyPart part1 = multiPart.getBodyParts().get(1);
>>> MyBean bean = part1.getEntityAs(MyBean.class);
>>> ...
>>> multiPart.cleanup();
>>> }
>>>
>>> The need for cleanup() is because the implementation knows how to buffer
>>> "large" body parts to temporary files on disk, so you don't blow away
>>> your JVM heap on a multi-gigabyte upload or download. I'm looking for a
>>> way to avoid the need for the application to call this, but haven't
>>> found one yet -- in the mean time, everything else about dealing with
>>> multipart files has seemed pretty easy to deal with.
>>>
>>> As mentioned above, this module works on the client side as well, if
>>> you're using jersey-client. The unit tests have some more worked-out
>>> examples of the lower level details.
>>>
>>> Give it a try and see what you think! And, for sure, if you see
>>> anything that needs to be improved, please ask here and/or file an issue
>>> in the issue tracking system.
>>>
>>> Craig McClanahan
>>>
>>> PS: Among my other interests will be working with the Atom Publishing
>>> Protocol support, again with the idea of leveraging JAX-RS providers to
>>> do format translations for custom <content> payloads.
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>
>>>
>>>
>>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>
>
--
View this message in context: http://n2.nabble.com/Hello-World%21-and-Welcome-to-jersey-multipart-tp1343189p1452334.html
Sent from the Jersey mailing list archive at Nabble.com.