Hi Dave,
I think the only way to currently guarantee this is to utilize the
MIME pull API directly [1]:
https://mimepull.dev.java.net/
(See the example on that page).
Currently there is no message body reader to support
org.jvnet.mimepull.MIMEMessage but you should be able to support this
directly as follows:
@POST
@Consumes('"multipart/mixed")
public void post(InputStream in, @Context HttpHeaders headers) {
MIMEMessage mm = new MIMEMessage(in,
headers.getMediaType().getParameters().get("boundary"),
mimeConfig);
}
Please log an issue if you want such support added to the jersey-
multipart module.
However, you will not get the access to the parts as Java types you
like. To do that i think we need a simple wrapper around MIMEMessage.
Paul.
On May 26, 2009, at 4:11 PM, Buccola_David_at_emc.com wrote:
> I'm trying to perform efficient streaming of potentially large
> multipart data. I don't want to hit disk. I noticed in the 1.0.3
> release notes the following reference:
>
> "The parsing of Multipart MIME now uses the MIMEPull API which
> provides efficient stream-based processing"
>
> I can't figure out how to use streaming yet. I have a method
> declared something like this:
>
> @POST
> @Consumes("multipart/mixed")
> @Produces({MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON})
> public Response postObjectWithContent (@Context HttpHeaders
> headers, MultiPart multiPart) throws Exception
>
> I've found that that MultiPartReader that gets invoked to service
> this request seems to parse the entire MIME message up front because
> of the call to MIMEMessage.getAttachments().
>
> What am I doing wrong? What do I need to do in order to get stream-
> based access to MIME parts without preparsing and copying them to
> disk?
>
> - Dave Buccola
>