-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
TS,
On 6/1/2009 3:15 PM, trojansnake12 wrote:
> Basically, what I am sending to the server is a byte array that is a picture
> taken from a cell-phone camera. My client-side code looks like this:
>
> url = new URL(urlString);
> connection = (HttpURLConnection) url.openConnection();
> connection.setDoInput(true);
> connection.setDoOutput(true);
> connection.setUseCaches(false);
> connection.setRequestMethod("POST");
Don't forget to set the Content-Type and Content-Length headers like this:
connection.setRequestProperty("Content-Type",
"image/jpeg");
connection.setRequestProperty("Content-Length",
String.valueOf(filesize));
> dos = new
> DataOutputStream(connection.getOutputStream());
> dos.write(Global.rawImage);
I'm not sure what Global.rawImage is, but you might want to stream the
upload with a small buffer so you don't have to keep the entire image in
memory. The use of an object like "Global" leads me to believe that some
sloppy programming is at work, here... a Global image? Hmm...
> dos.close();
It can't hurt to flush() this stream before closing it. You didn't post
any of the other code, but error handling is essential on the client.
> Now what I need the server to do, is to write this image to a file in the
> directory /webapps/geosim/DRimages/.
You may be barred from doing this based upon the deployment semantics of
the web application. It's better to plan ahead for that eventuality.
What I like to do is use <init-param> elements in my web.xml to define
things like this:
<servlet>
<servlet-name>myImageUploaderServlet</servlet-name>
<servlet-class>[whatever]</servlet-class>
<init-param>
<param-name>imageUploadPath</param-name>
<param-value>/full/path/to/destination/directory</param-value>
</init-param>
</servlet>
You can get the value of the init-param like this:
super.getInitParameter("imageUploadPath")
> DataInputStream is = new
> DataInputStream(request.getInputStream());
A DataInputStream is not appropriate for this application:
DataInputStream is used to read Java primitives from a byte stream.
Since you aren't reading anything but bytes, you should use a simpler
form of InputStream. BufferedInputStream is a good choice, though the
ServletInputStream returned by request.getInputStream might already be
buffered, so you either get nothing, or get worse performance by having
two differently-sized buffers.
> raw = new byte[800000];
Again, I recommend a streaming approach... no need to load the entire
image into memory before writing it to the disk.
> for(i=0; i<800000; i++)
> raw[i] = '\0';
Why bother zeroing-out this array? Java will already give you an array
of bytes whose values are '\0' (or just zero, if you prefer).
> i = 0;
> len = 0;
>
> while((i = is.read(raw)) != -1) {
>
> }
That's an interesting idiom. I had to read it several times to convince
myself that it would actually work. I'm still not quite convinced, but I
guess InputStream.read(byte[]) is guaranteed to block until enough bytes
have arrived to full the buffer, or the byte stream ends.
If your image is bigger than 800000 bytes, you'll have a problem, though.
> file = new File(filePath + d.getTime() + ".jpg");
Depending on what 'd' is, this might run the risk of overwriting files.
> fos = new FileOutputStream(file);
> fos.write(raw);
> fos.close();
If you stream this, you'll want to buffer the output. Also, flush()ing
never hurt anybody :)
> Could you guys help show me how to do this using the ServletContext resource
> handling? I'm unfamiliar with how to do this.
Since you're /writing/ files and not reading them, Chuck's suggestion of
using getResourceAsStream isn't going to help, because you need
something like "putResourceAsStream" which doesn't exist.
I recommend my technique shown above using init-params, and putting the
destination directory /outside/ the webapp deployment directory. In the
off change that you re-deploy your web application at some point, you
might end up deleting all the files in the deployment directory. This
technique encourages you to put the files elsewhere, possibly protecting
yourself.
Good luck,
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkokSzUACgkQ9CaO5/Lv0PCaBgCfQSKaHsei1TaaHG/Tdpr9cOYp
s0AAn1Epx3xvpV0ZMk9cV7W6hXeVHzZ6
=dXp0
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
