Kevin Duffey wrote:
> I will have to use this API shortly to handle file upload/download
> myself. I am sure with Craig's help I'll get it working.. just
> wondering if there is anyone using it already that is able to combine
> a normal REST POST/PUT call with xml body.. and actual file data and
> has it working... would be great to see an example of code on both the
> client and server that can handle this. If not, maybe after I get it
> working with Craig's/Paul's permission I can add it as an example or
> to the contrib. That will be some time tho.
>
It might be a little too small to qualify as a sample with "actual file
data", but the unit test class
(com.sun.jersey.multipart.impl.MultiPartReaderWriterTest.java) and the
associated test resource class (MultiPartResource) do have code snippets
for both sending and receiving multipart/mixed requests. The data is
real small text/plain or text/xml things, but that's the easy part ...
dealing with entities in a body part is pretty much like dealing with
them on regular JAX-RS calls
It would be great to have a more fleshed out sample.
Craig
> ------------------------------------------------------------------------
> *From:* Gili <cowwoc_at_bbs.darktech.org>
> *To:* users_at_jersey.dev.java.net
> *Sent:* Thursday, November 20, 2008 11:39:27 PM
> *Subject:* Re: [Jersey] jersey-multipart throwing NPE
>
>
>
> Craig McClanahan wrote:
> >
> > For *all* HTTP headers, it is legal to have multiple values for the
> same
> > header, so a general purpose API has to support that option. For the
> > simple case where you know there is only one value (or for where you
> > don't care about anything other than the first value), try this:
> >
> >
> bodyPart.getParameterizedHeaders().getFirst("Content-Disposition").get("name");
> >
>
> Yeah, I just remembered this when reading an older post you made about
> ParameterizedHeaders. <shudder> HTTP headers sure are complex.
>
> Okay, so I'll get cracking using this new API but I would like to humbly
> suggest you need to explain a lot of these details in the Javadoc. It
> should
> be easier for end-users to pick up on these concepts without reading
> through
> the HTTP specification. I suspect that even developers who are quite
> familiar with HTTP will drop the ball on the HTTP header complexity.
>
> I would suggest you write something along the following lines:
>
> [...]
> Here is a sample HTTP header:
> Content-Disposition: attachment; filename=bear.jpeg;
> inline; filename=panda.jpeg;
>
> The above header means: ("Content-Disposition=attachment" and
> "filename=bear.jpeg") or ("Content-Disposition=inline" or
> "filename="panda.jpeg")
>
> Here is some sample code for parsing the header:
> -
> bodyPart.getParameterizedHeaders().getFirst("Content-Disposition").getParameters().get("filename")
> returns "bear.jpeg"
> -
> bodyPart.getParameterizedHeaders().get("Content-Disposition").get(1).getParameters().get("filename")
> returns "panda.jpeg"
> [...]
>
> BTW: Please note how long this API is turning out to be. Instead of
> getFirst("Content-Disposition").getParameters().get("filename") why don't
> you remove getParameters() and place get() directly on the
> ParameterizedHeader?
>
> Gili
> --
> View this message in context:
> http://n2.nabble.com/jersey-multipart-throwing-NPE-tp1560622p1560741.html
> Sent from the Jersey mailing list archive at Nabble.com
> <http://Nabble.com>.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> <mailto:users-unsubscribe_at_jersey.dev.java.net>
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
> <mailto:users-help_at_jersey.dev.java.net>
>
>