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.
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?
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.
Thanks,
Jeff
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