tags:

views:

562

answers:

5

I have a folder of static html,imgs,flash content that lives outside of the webapp folder. Right now I'm using a symbolic link to map that folder into my webapp directory. The problem i have is when I undeploy my application it follows the symbolic link and deletes all these files.

One of the solutions I'm trying to implement is a special servlet that wraps the default servlet but uses a different relative path. I'm having trouble finding out how to wrap the default servlet in a way that overrides the default servlet path.

Here is what I'm working with:

public void doGet(final HttpServletRequest req, final HttpServletResponse resp)
    throws ServletException, IOException {
    final RequestDispatcher rd = getServletContext().getNamedDispatcher("default");
    final HttpServletRequest wrapped = new HttpServletRequestWrapper(req) {

        @Override
        public String getServletPath() {
            return "/usr/depot/repository";
        }
    };

    rd.forward(wrapped, resp);
}
A: 

That's not a good idea.

Web containers or application servers can be deployed behind Web servers or you can simply use a Web server in conjunction with your container. Just put your static files under that and refer to them by absolute path.

There's really no need for this kind of hack (sorry but that's what it is).

Either that or simply deploy them with the Web app.

cletus
Unfortunately the content needs to be protected behind a security filter. We are already running apache httpd for most static content, but his folder is special. I agree it's a hack.
Ruggs
+1  A: 

You can either write your own servlet to serve static content (which is not that hard) or try to extend rather than wrap the DefaultServlet. Either way, your resulting servlet will have be configured in place of default in your web.xml (using "default" as servlet-name).

That said, DefaultServlet will only serve static content from under your webapp context; in order to change that you'll have to create / bind to JNDI your own ProxyDirContext instance pointing to the outside folder and I'm not sure whether that will work; its configuration process is rather involved.

Trying to override servlet path will not get you anywhere.

ChssPly76
+1  A: 

We have a similar problem that we need to share some files generated by CMS among several applications. Symlink is the easiest way to do this if you are not using Windows.

We setup 2 accounts for CMS and Tomcat. The files are read-only to Tomcat so it can't delete them.

You can also write a small Tomcat extension so it can look for files in multiple places. See this web site,

http://blog.bazoud.com/post/2009/05/12/Multiples-docbases-avec-tomcat

Your current approach won't work. Tomcat needs to load up all the resources in a cache on deploy for it to be available. It's too late to change that in request processing. This extension allows Tomcat load resources from multiple directories. The drawback of this approach is that you have to put a small JAR in server/lib.

ZZ Coder
I ended up deciding to just create my own serlvet that is mapped to a specific path. I have been using symlinks since the files are shared between multiple app nodes but must be writeable. This of course is not the ideal solution but the best given the requirements.
Ruggs
A: 

Very similar issue. I would like Tomcat to serve static content (we are not using Apache) but with a couple of 'smarts.' Any request that comes in for /html/foo.html I would like to have it check for /html/foo.html.gz first. If it is found (and the request header supports gzip encoding), then the Content-Encoding header is added with gzip and then the file returned is foo.html.gz.

The nice thing about this approach is that unlike PJL type 'on the fly' compression routines, the compression is done once, at build time, saving CPU and bandwidth.

Can I subclass DefaultServlet and get it to switch around which file it serves up. The files will be in the ProxyDirContext because they are generated during the build process.

John
+1  A: 

You can override DefaultServlet with your own implementation. You can perfectly subclass it, it's a public class. Here are the functional specifications of the DefaultServlet, you need to adhere it.

On the other hand you can ignore DefaultServlet and go for your own solution, an example can be found here.

BalusC