This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
I have a project with a servlet that compiles in several stages. In the first stage, I use an ant script to build a directory full of plain old static web content including HTML and JPG files.
In my second stage, I'm building a servlet that processes user input and then forwards the request to one of several JSP pages for formatting. I'd like the JSP files to be able to reference the JPG files I put in my archive in the previous step. I thought that if my JSP generated a page that included a tag like<img src="file:///c:/path_to_archive/myImage.jpg"/> that this would work, but I'm guessing that GlassFish is refusing to resolve any URL that starts with file://. (My plan was to pass in the URL prefix of my archive as an initialization parameter and then have the JSP generate references that point into my archive).
What's the best way for me to reference my archive from my servlet? I could manually copy each of the JPGs into the /web directory of my servlet, but this will leave me with a huge WAR file. (I'll also have to recompile and redeploy each time I changes the images.)
I'm also worried that my JPGs may not be cached the way they would if they were served from an ordinary static page server. (I'm really not sure how caching works with servlets. If I use a URL to point to a static JPG stored inside my WAR, will that be served fresh each time my page is hit, or will it be potentially cached on a remote machine?)
A file:// URL references files on the client computer, not on the server. A webserver is NOT a fileserver.
To resolve image and other static resource object requests on the server side, you have to either place them in places where the default servlet can see them or provide a resource resolution mechanism of your own.
The default servlet is an invisible servlet that's part of your webapp server. Any URL request that can't be routed to a JSP or servlet goes to the default servlet, which figures out how to handle that URL. For things like image, script and css resources, the default servlet will dissect the URL to obtain the core resource path, then look inside the WAR for an object located at the target of that path. Meaning that resource "/images/pic123.jpg" will be retrieved (if possible) from the "images" directory under the WAR's root.
If you want to keep your images inside an archive file or in some external location, that's fine, but you'll have to provide a servlet that knows how to interpret requests, pull the data out, and copy the data to the Response stream just like the default servlet does for resources in the WAR.
Caching isn't done by the server. Caching is done by the client. You can modify the client's caching behavior by supplying appropriate cache headers in the Response stream.
An IDE is no substitute for an Intelligent Developer.