Thread: Web app image processing from stream to UIComponent

Hi all,

We are using Eclipse Galileo, Java 1.6, JSF 1.2, Facelets, IceFaces 1.8.2, to develop web applications.

We would like to place all our sensitive image files into a jar and then deliver them to the browser. To do this we are trying to 1) retrieve the image from the jar file, 2) write the image to a temp file location, and 3) point the image tag to the temp location (<img src=”tempPath/image.gif”> ).

We have successfully done the first two steps and verify the images are written correctly but can not access the temp file in the third step. Here are the details:

private String writeFile(InputStream is) {
String path=null;
try {
File newPath = File.createTempFile("ae", ".gif", null);
byte buf[] = toByteArray(is);
OutputStream f1 = new FileOutputStream(newPath);
f1.write(buf);
f1.close();
path=newPath.getPath();
} catch (FileNotFoundException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
}
return path;
}

private byte[] toByteArray(InputStream input) throws IOException {
ByteArrayOutputStream output = new ByteArrayOutputStream();
byte[] buf = new byte[4096];
int len = 0;
while ((len = input.read(buf)) > -1){
output.write(buf, 0, len);
}
return output.toByteArray();
}

We then try to pass the String path property of this Backing Bean in Facelets as follows:

<img src="#{BackBean.imgPath}" width="50" height="100" alt="desc"></img>

This is the first time we have tried to present images in this way. Not sure that it is possible to access even a temporary image from the client machine. Are we doing something wrong? Is there another way to accomplish the same thing (i.e., secure the images or obfuscate the path)?

Your assistance is greatly appreciated.

TC

Is your goal to offer an URL for an image that is only reusable for a short period of time, or only for a limited number of requests?

Not sure that it is possible to access even a temporary image from the client machine

Have you tried testing this part of the project by manually creating the HTML and positioning the image file to see if the browser will get the image from a local file.
I think you need to figure out the src=url to see if it is even possible.

Hi Sean4u,

Our forth step would be to delete the temp file as the client session ended. The image would be available on the client machine and available for reuse by the web app until then.

TC

Hi Norm,

Good question. Our attempts to test that failed. By that I mean that we created several image files by the means defined above that were not deleted at the end of the session. Using an absolute path to the new image file - we were not able to produce the image to the web page's UIComponent. Perhaps you just cannot do that. Looking at my workstation I have so much vender junk in my temp folder, I find it hard to believe these files are not being accessed repeatedly.

TC

When I tried loading an HTML file from a server with <IMG src=file://... the browser gave me a security error

Too many hours. I said client machine above of course I meant web app server. I am running a version of Tomcat on my workstation as localhost so its both for now. It looks like our next test will be to try and create the file within the web app context and see if that works for us.

Sorry Norm, not sure what your doing inside that image tag.

TC

I was thinking of a solution for a problem I see with a lot of html pages that load many files from a server instead of loading one large file like a zip file and then extract its contents to use when displaying the page. Get all the needed images etc with one net I/O vs many.
Java applets put all their files in a jar file that can be loaded with one net I/O. So I was wondering how you could do it with images etc for an HTML page. One net I/O gets all that is needed for the page.

many files from a server instead of loading one large file like a zip file

There's usually no point in zipping images because they're already compressed. What a lot of big sites do is glue all their images together in a big patchwork blanket and send the 'megaimage' in one go and use positioning and cropping in the browser to re-use the same image over and over, but show different parts in different places. It's not so bad anyway, unless you're distant from the server so that the return-trip from the end of one image to the beginning of the next response is a large fraction of (or even greater than!) the transfer time of the image.

What is your essential problem? Is it that you need to convert a filesystem path for a temporary file to an URL so that you can create files somewhere where your users can request them? There ought to be a simple crude solution and also a cunning one that Tomcat provides. My application server doesn't naturally do HTTP file serving, so I have to explicitly map every servable native file to a client-side URL. You should be able to just kludge it by doing a string replace on the filesystem path prefix of the temporary directory with a valid URL prefix for the same files. If your temporary files are not in a part of your filesystem that's accessible to Tomcat (will it be the Apache DocumentRoot?), then you may have to write some code to manually read bytes from the files and send their content.