The folder contains .jpg files
Need to open file that is intercepted.
for some reason this(req.getPathTranslated()) is null, hence not usable.
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
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 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.
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.
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:
If you could point me to how to get file & file name (since it contains database id for getting opt. wattermark coordinates) from response ....
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?
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.
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).