Created attachment 27978 [details] some code to look at. The attached code allows tomcat to merge in one or more partial webapps to build up the definitive webapp. I wrote this code to support a particular development/debugging methodology. I have a launcher program that uses the embedded API to launch tomcat with a webapp with the static materials sitting where they sit in my dev tree, and the classpath for the webapp taking the classes where eclipse writes them as well. The result is live debugging. I wanted to extend this to the case where some of my static content was merged in from 'overlays' in the maven-war-plugin sense of the term, and I came up with the attached. You may think it's nuts. You may think that it points up some modularity issues around the context classses; there are an awful lot of tests for instanceof and casts in this neighborhood. If you have some sympathy for this idea, I would be willing to refine it and/or work on an associated patch to change the modularity around DirContext/BaseDirContext/StandardContext to make it less ugly to create.
Personally, I am of the view that this is a build time problem rather than one that should be solved at runtime. However, Oracle does not agree with me and it looks like something along these lines will be required as part of the next version of the servlet spec. Until the requirements are firmed up it is hard to know what the best implementation approach will be. My preference will be for the simplest code that does the least possible amount of work "on the fly".
My experience is that I can get work done on webapps much, much, faster if I operate in a mode where modified files are directly read by the web server. If I have to run a build every time I want to see the results of a change, I'm sad. As far as build-time goes, that's all covered by the maven-war-plugin. Further, you might call this just an alternative to the setResourceJar feature that accepts multiple webapp-shaped dirs instead of one META-INF/resources. However, I don't expect you all to buy a bridge from me. Slightly tangentially, do you have any sympathy for my view that something like this could easier with some sort of refactoring of the Context class family? I feel somewhat presumptuous. It seems like I shouldn't have had to create a wierd subclass of FileDirContext in addition to a subclass of StandardContext -- Or maybe I should just done the MultiDirContext and passed that into setResources of an ordinary StandardContext?
I'm a big fan of re-factoring. One of the things on my todo for Tomcat 8 is to at least look at removing all the JNDI stuff from DirContext JNDI stuff and simplify all that code. Anything that cleans-up and/or simplifies the code is welcome. 7.0.x is probably beyond the point where we want to make bug changes but we have free reign in trunk. Aliases are along a similar line to overlays (for static content). It may be worth extending aliases / combining your ideas with the current code (he says without having had a chance to look at your patch).
Aliases, if I have it right, say 'substitute in a tree of static content *here*'. The patch says, 'first look in this webapp-shaped directory, then the next, then the next, then finally the 'real' one. I'll have a look at trunk refactoring.
I have been working on bug 51741 for some time now and will commit something in a couple of days. I think it will be useful to you.
This was implemented in Tomcat 8 as part of the resources refactoring.