This week's book giveaway is in the OCAJP forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide 1Z0-808 and have Jeanne Boyarsky & Scott Selikoff on-line! See this thread for details.
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.
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.
Joined: Nov 23, 2010
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:
If you could point me to how to get file & file name (since it contains database id for getting opt. wattermark coordinates) from response ....
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).
Customer surveys are for companies who didn't pay proper attention to begin with.