filter, get file from request

[Miran Cvenkel]

web.xml is set up so that filter intercepts all requests to certain folder.
The folder contains .jpg files

Need to open file that is intercepted.

for some reason this(req.getPathTranslated()) is null, hence not usable.

File file = new File(req.getPathTranslated());  

Neither of those works, doh the vaues of URI and URL are OK( something.....jpg), that is from file beeing requested.
I get file.exists() = null in both cases

File file = new File(request.getRequestURI());
File file = new File(request.getRequestURL().toString());

[Bear Bibeault]

Miran Cvenkel wrote:Need to open file that is intercepted.

What file? There is no file that is part of the request.

Are you doing a file upload? If so then the file contents, not the file itself, is embedded in the multi-part request.

Perhaps you should back up a few steps and tell us what you are actually trying to accomplish.

[Miran Cvenkel]

Yeah, no file is part of the request, but file path is in form of URL and URI.

<img src = "the_folder/a.jpg" ...

This gets to server filter which should modify all files served from 'the_folder' , before response.

In filter, I get for URL and URI values like ...the_folder/a.jpg.

[Bear Bibeault]

So the file name is part of the URL. (That's not the same as saying that the file is part of the request.)

So you want to intercepts request to images, and do something to them. What?

[Miran Cvenkel]

Print wattermark on it, doh I don't see how would that info contribute to solving my problem.

[Bear Bibeault]

Miran Cvenkel wrote:Print wattermark on it, doh I don't see how would that info contribute to solving my problem.

Knowing what you want to do has everything to do with your question. How can we help you do something if we don't know what it is? I suggest a change in strategy: exposing such a poor attitude isn't likely to make people want to volunteer their time to help you.

In any case, I don't think a filter is a good choice for this. Rather, I'd map the image requests to a servlet than can read the image file, apply the watermark, and stream it as the response.

[Paul Clapham]

I don't see why knowing the name of the file you're going to return would contribute to solving your problem either.

Of course that's mostly because I don't know what the requirements are. It's quite likely that you've taken the requirements and run a long way down the wrong road, in which case the answer to "How do I get there from here?" would be "Go back and start again." But again, I don't know what the requirements are so I could be wrong.

My guess is that your URL actually points to an image file which you want to return, and that without the filter the image file would be returned as is. But you want to modify that file by watermarking it before it's returned to the browser.

Personally I would solve this problem by watermarking the images before allowing them to be downloaded, and then doing no programming at all. However if I found I couldn't do that, I would have my servlet filter intercept the response and apply the watermark before resending it. That doesn't require manipulating any URLs at all. And note, it's the response you want to get the file from, not the request.

However if that isn't your problem, tell us what is.

[Miran Cvenkel]

My apologies. I tent not to write novels as I'm concentrating on specific problem, and I'm not expecting people would be willing reading long posts (same as me).

Paul Clapham wrote:
And note, it's the response you want to get the file from, not the request.

Hmm, interesting thought.

1. I found myself having tons of images, not watermarked, so applaying watermark manualy is not a good idea.
Besides, I think, mybe one day having backup of not watermarked image on server could come handy and I need image untouched while editing it on client side.
2. So by default, same text for all images is printed in center of image, since that can be bad, I record x,y coordinates of opt. manual coordinates by java script & save that in db.

so currently, filter:

  /*get name of file (from request) , get opt coordinates of wattermark for that file from db, get file object, */
  BufferedImage buffer = ImageIO.read(file);/*  -->manipulate that*/
  response.setContentType("image/jpg");
  OutputStream os = response.getOutputStream();
  ImageIO.write(buffer, "jpg", os);
  os.close();

If you could point me to how to get file & file name (since it contains database id for getting opt. wattermark coordinates) from response ....

[Bear Bibeault]

Miran Cvenkel wrote:1. I found myself having tons of images, not watermarked, so applaying watermark manualy is not a good idea.

Use Photoshop batch processing. It's senseless to do this in real time rather than in batch.

so currently, filter:

If you insist on doing this every time the image is requested, don't use a filter. Not a good match for this purpose. See my previous reply.

If you could point me to how to get file & file name

Are the images part of the web application?

[Bear Bibeault]

Miran Cvenkel wrote:My apologies. I tent not to write novels as I'm concentrating on specific problem, and I'm not expecting people would be willing reading long posts (same as me).

Your posts don't need to be long -- in fact, too long and yeah, they wont get read. But they should be complete.

This is a classic "XY problem". You need to do X, have decided that you should do Y, and ask about Y, leaving X off. We need to know what X is.

[Tim Holloway]

You should NEVER store a file in a WAR. Always store it in an external directory. If you're lucky, it will fail. If you're not, you'll end up setting yourself for a lot of grief someday, and Murphy's Law dictates that that won't be the day you really want to deal with the consequences.

When a J2EE app "uploads a file", what really happens is that a multi-part MIME-encoded form HTTP POST is sent to the server with the contents of the file being part of the MIME-encoded data. The server will decode that data and store it in a temporary holding area. You must then copy that data to its permanent home (if any), which should be some place that's external to both the web application server directories and the web application WAR. The temporary holding area may not actually be a disk file - at the server's discretion, the data could be held in RAM if certain conditions are met, or even in more exotic types of storage. So only read the upload data using the upload API, not brute-force filesystem calls.

The metadata that accompanies the file contents includes the "filename", but not all clients mean the same thing when they say "filename". Firefox, for example, only sends the actual simple filename. Internet Explorer may send the entire source computer filesystem absolute pathname (which is a security exposure as far as I'm concerned).