If I run a spring boot app(jar file) I see a couple of directories being created. Work directory and a 'tomcat-docbase*' directory
tomcat..8080 tomcat-docbase..8080
The default base directory can be overridden using the config property server.tomcat.basedir. However, this has no effect on tomcat-docbase. It is possible to override tomcat-docbase directory path or stop it from creating as in my jar there are no static files being served.
Comment From: wilkinsona
It is possible to override tomcat-docbase directory path or stop it from creating as in my jar there are no static files being served.
There's no easy way to do so at the moment. You should be able to delete the default docbase and configure another one using a TomcatContextCustomizer. Something like this:
@Bean
public EmbeddedServletContainerCustomizer containerCustomizer() {
return (container) -> {
if (container instanceof TomcatEmbeddedServletContainerFactory) {
((TomcatEmbeddedServletContainerFactory) container)
.addContextCustomizers((context) -> {
String docBase = context.getDocBase();
FileSystemUtils.deleteRecursively(new File(docBase));
File file = new File("custom-doc-base");
file.mkdirs();
context.setDocBase(file.getAbsolutePath());
});
}
};
}
Can you please describe why the current behaviour is causing you a problem? It will help us to decide if the above approach is sufficient or if a configuration option is warranted.
Comment From: RohitGupta31
Thanks.
The reason being if we stop the application abnormally there is a new tomcat-docbase being created which keeps on increasing the disk size. Digged around the embedded tomcat code a bit, found another alternative way to fix it by creating a directory called public in the same directory where jar is copied and that prevents from creating tomcat-docbase directories.
But it would be better if you can add a config option for this.
Comment From: wilkinsona
If DocumentRoot.getValidDirectory() is able to return a non-null value it will be used as the doc base. We wouldn't want to override that with a directory provided by configuration as it may cause problems such as stopping static resources from being served. In other words, if the doc base is made configurable, we'd only want to honour the configuration setting when DocumentRoot.getValidDirectory() returns null. I think that will be confusing.
I think a better solution would be, if possible, to allow Tomcat to run without a docbase. However, that will take longer assuming it's possible at all.
Comment From: wilkinsona
@markt-asf would it be possible for Tomcat to run without a docbase? Right now, when running with a fat jar, we point Tomcat to an empty temporary directory as we have nothing else to point it to.
Comment From: markt-asf
Tomcat 8.5.x and 9.0.x will run with a null docBase and have done since this commit: http://svn.apache.org/r1635222 8.0.x and 7.0.x still require a docBase. I haven't looked into the refactoring that would be required to support this in these older versions. Is support for this in 8.5.x and 9.0.x enough?
Comment From: wilkinsona
Thanks Mark. Sorry, I clearly should have tried this again with 8.5 rather than relying on the out-of-date knowledge of how things used to be. Support in 8.5 (and 9) is enough for us.
Comment From: wilkinsona
Unfortunately, we can't configure Tomcat with a null docbase as it will regress the fix for https://github.com/spring-projects/spring-boot/issues/2878. Things have been this way across all three containers since 1.3.0. We'll have to live with that for a little bit longer.
Comment From: philwebb
We're cleaning out the issue tracker and closing issues that we've not seen much demand to fix. Feel free to comment with additional justifications if you feel that this one should not have been closed.
Comment From: hurelhuyag
I just realized spring-boot creating an empty directory in /tmp. My CI/CD server bunch of tomcat.0.11674077944490226022 directories. It doesn't consume much space. But it is inconvenient. If we could stop creating that directory. We should.
Comment From: nmwael
we were hit by this, when hardening our container images.
We've tried adding a empty public in resource root. this does not stop the call to create tmp folder.
cutout of exception:
│ org.springframework.boot.web.server.WebServerException: Unable to create tempDir. java.io.tmpdir is set to /tmp\n\tat org.springframework.boot.web.server.AbstractConfigurableWebServerFactory.createTempDir(AbstractConfigurableWebServerFactory.java:221)\n\tat org. │
│ springframework.boot.web.embedded.jetty.JettyServletWebServerFactory.configureDocumentRoot(JettyServletWebServerFactory.java:319)\n\tat org.springframework.boot.web.embedded.jetty.JettyServletWebServerFactory.configureWebAppContext(JettyServletWebServerFactory.j │
│ ava:266)\n\tat org.springframework.boot.web.embedded.jetty.JettyServletWebServerFactory.getWebServer(JettyServletWebServerFactory.java:174)\n\tat org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext.createWebServer(ServletWebServerAppl │
│ icationContext.java:188)\n\tat org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext.onRefresh(ServletWebServerApplicationContext.java:162)\n\t... 8 more\nCaused by: java.nio.file.FileSystemException: /tmp/jetty-docbase.443.712082876813 │
│ 9561313: Read-only file system\n\tat java.base/sun.nio.fs.UnixException.translateToIOException(Unknown Source)\n\tat java.base/sun.nio.fs.UnixException.rethrowAsIOException(Unknown Source)\n\tat java.base/sun.nio.fs.UnixException.rethrowAsIOException(Unknown Sou │
│ rce)\n\tat java.base/sun.nio.fs.UnixFileSystemProvider.createDirectory(Unknown Source)\n\tat java.base/java.nio.file.Files.createDirectory(Unknown Source)\n\tat java.base/java.nio.file.TempFileHelper.create(Unknown Source)\n\tat java.base/java.nio.file.TempFileH │
│ elper.createTempDirectory(Unknown Source)\n\tat java.base/java.nio.file.Files.createTempDirectory(Unknown Source)\n\tat org.springframework.boot.web.server.AbstractConfigurableWebServerFactory.createTempDir(AbstractConfigurableWebServerFactory.java:215)\n\t... 1 │
│ 3 more\n"}