Thanks Craig! This all sounds good.
I guess my client side question was more generic. Potential clients
may be using Java, Python, Ruby etc. and whatever related libraries. I
don't know if issuing multi-part requests is unusual or difficult in
general for such clients. I don't want to put up anymore barriers to
entry to use the API then I have to. :) What has been your experience
in this regard? Any complaints from clients?
Cheers,
Jeff
On Oct 23, 2008, at 1:10 PM, Craig McClanahan wrote:
> Jeff Schmidt wrote:
>>
>> Hi Craig:
>>
>> Thanks for your work on jersey-multipart. I have some SOAP based
>> endpoints where a request can consist of various XML meta data, and
>> then there is an element of type base64Binary where an arbitrary
>> file can be 'attached' to the request. I would like to do
>> something equivalent in a RESTful manner. It seems like a request
>> comprised of an XML entity and a binary entity would be the way to
>> go. The JAX-RS resource does not need to understand the binary
>> entity, just make it available to some server-side code.
> Yep, that is exactly the sort of thing I use it for.
>>
>> Looking at some of the jersey-multipart code, it looks like I can
>> use BodyPart.getEntityAs(MyMetaData.class) to access the XML meta
>> data, and BodyPart.getEntity().getInputStream() to access the
>> binary data. When I'm done, MultiPart.cleanup() will delete the
>> temporary binary file (if > threshold bytes). Am I reading that
>> right?
>>
> That's exactly right.
>> Also, I don't know if doing this on the server side will make it
>> difficult for clients. You said the jersey-client can easily work
>> with jersey-multipart. I've not yet looked into the Commons
>> HttpClient or other client libraries to see if they have issues
>> with making multipart requests.
>>
> You can also look at the Jersey client code itself. One of the
> really cool things about jersey-client is you can use the same
> providers (including the jersey-multipart stuff) on the client just
> like you can use it on the server. There's some small samples of
> this in the jersey-multipart unit tests.
>
>> Thanks,
>>
>> Jeff
>>
> Craig
>
>> On Oct 17, 2008, at 12:58 AM, Paul Sandoz wrote:
>>
>>> Hi Craig,
>>>
>>> Welcome to the list of Jersey committers :-)
>>>
>>> Thanks very much for the multipart MIME contribution, it looks
>>> really good. I would like to leverage this to improve the support
>>> for multipart/form-data and also consider support for Multipart
>>> Java Beans.
>>>
>>> Classes supporting AtomPub support would be great!
>>>
>>> Re: the cleanup aspect. I think we need to review Jersey's IoC
>>> support and integration capabilities with the likes of Spring/
>>> Guice. It is really hard to be abstract from an IoC framework :-
>>> ( If the returned MultiPart was instantiated in the life-cycle of
>>> the request then when the response is about to the sent a pre
>>> destroy method could be called to do the clean up. That would not
>>> work for the conditions of the client working standalone (perhaps
>>> cleanup could also be called before being GC'ed although that
>>> cannot be relied upon).
>>>
>>> Paul.
>>>
>>>
>>> On Oct 17, 2008, at 1:00 AM, 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
>>>
>>
>>
>>
>> --
>> Jeff Schmidt
>>
>>
--
Jeff Schmidt