Community
Participate
Working Groups
Build Identifier: Jetty 7 According to the javadoc for WebInfConfiguration.resolvTempDirectory, if no explicit temporary directory is set, Jetty normally chooses to create a webapp temporary directory in $(java.io.tmpdir). However, if it finds a directory named "work" in certain places Jetty will choose to use that work directory instead of a temporary directory. When it makes that choice, it also does not delete the directory's contents, so it behaves differently in this regard. If $(jetty.home) is undefined, one of the "certain places" where Jetty looks for a directory named "work" can include the current working directory. This can lead to confusion when jetty behaves differently just because there is a directory with a particularly common name lying around somewhere. I don't know whether this default behavior regarding "work" can be eliminated. Jan B. said in an email that it was "historical... something that Tomcat originally did." If it can't be eliminated, I would like a way to configure jetty that avoids this counterintuitive behavior. One way would be to have an option that just turns off this search for "work". Alternatively, it would also suffice have an option to insist on Jetty's using $(java.io.tmp) AND always deleting the contents before deployment and after shutdown. Reproducible: Always Steps to Reproduce: 1. Run an application with embedded Jetty that does not define $(jetty.home), in a working directory that contains a subdirectory named "work".
The work directory is a feature not a bug:) There are applications that wish to use have their "temporary" files retained from one run to another - compiled JSP classes are one example of this. The naming convention of a "work" directory that keeps it's contents is differentiated from a "temp" directory that does not. If you explicitly set a temp directory on a context, you will avoid the search for a work directory. Alternately you could replace the WebInfConfiguration class in the servers configuration list, with your own implementation that extends the original but has a different implementation of resolvTempDirectory.
