Thanks... I'm going to read that a few times to make sure it soaks in!
I appreciate the help!
On Oct 9, 2009, at 2:41 PM, Sergey Beryozkin wrote:
Hi John
Thanks for posting the code and confirming it's working ok.
I'm leaning along myself too, but here's what I think.
Receiving multipart messages on the server side is beneficial when you
have multiple documents to receive or when uploading a file from HTML
forms.
Even sending a single but huge file can probably be better done with
multiparts due to CXF saving the file to a temp storage along the way.
It can make sense sending the multiparts (server-client) if you'd like
to have multiple docs/files returned; if it's a single but huge file
then you can probably avoid multiparts by applying a gzip feature to
it.
The possible disadvantage is that it is a bit more difficult to handle
multiparts from directly the custom code (on the client side).
By the way, you can have InputStream accepted/returned but also
specify
multiple produces/consumes values :
@Produces({"pdf", "jpg", "etc"})
@Consumes({"pdf", "jpg", "etc"})
InputStream acceptStreamReturnStream(InputStream is) {
}
When/if dealing with multiparts on the server side you might try
adding
MultipartRequest to a method signature - it will make it easy to get
to
individual parts, get headers like Content-Disposition, etc
Cheers, Sergey
-----Original Message-----
From: John Klassa [mailto:[email protected]]
Sent: 09 October 2009 19:16
To: [email protected]
Subject: Re: sending/receiving a file in a JAX-RS (JSR-311)
application
Uploading multiparts is also supported, see...
Thanks for the response!
I guess where I was coming from was this: On the server (receiving a
file) side of things, I have code that works (nicely, even -- it
streams the data [transparently to me], and doesn't out-of-memory on
large files)... It's copy/pasted below, for reference. What I was
wondering is whether this approach is *reasonable*. :-) And if not,
what do people recommend instead (as a "standard", if you will).
As it is, this code lets a client send me a file with arbitrary
content, and I can receive it and store it on my end (in a domain-
appropriate way). And as it happens, I've verified that I can write a
perl client easily enough, that also works nicely with this approach.
Is there a reason not to do it this way, though? Is a multipart,
encoded-somehow-or-another approach better for reasons that aren't
obvious to me, as a newbie to this?
On the sending side (server to client), is there a reason not to send
in the analogous fashion -- as application/octet-stream? Seems like
the only real down side is that, because the MIME type is generic,
doing something like pointing your browser at the URI for a resource
that happens to be a JPG (for example) won't yield the intuitive
result; rather than just being shown the image, you'll be asked where
you want to save the download.
Thanks for your insight and guidance!
Server-side:
@POST
@Path("/{name}")
@Consumes("application/octet-stream")
public void addFile (@PathParam("id") String id,
@PathParam("name") String name,
InputStream text)
throws Exception
{
FileOutputStream fos =
new FileOutputStream(new File("/tmp/attachment"));
copyStream(text, fos, 16384);
fos.close();
}
}
Client-side:
WebClient client = WebClient.create("http://127.0.0.1:8080/CXFPlay/
rest");
InputStream inp = new FileInputStream(args[2]);
Response res =
client.path("defect/" + args[0] + "/file/" + args[1])
.type("application/octet-stream").post(inp);
