Caching Defaults changes don't persist


On a new GeoServer install:

  1. Go to Caching Defaults page

  2. Check "Direct Integration"

  3. Click "Submit"

  4. Restart Tomcat

  5. Go to Welcome Page

  6. Go to Caching Defaults page

Direct Integration won't be checked...

It looks like the change never makes it to the gwc-gs.xml file, which still reads:



Tomcat WAR on Windows 10


Andrea Aime
July 30, 2016, 8:58 AM

Hi Mike, commenting on Jira is like talking to yourself, there is no one reading the messages past the ticket creation one. I'd recommend to discuss on the devel or user list instead.
That said, no, I am not aware of similar issues (or this one in particular, for what is worth). I don't have a GS handy locally, but I tried with which is the current day's nightly build, and checking the changes via the resources REST api, e.g., "", which returns the files in the data directory. It appears that I can turn on and off the direct integration, and the changes appear to be persisted.
Could it be a local problem in your installation? Maybe windows specific?

Torben Barsballe
September 7, 2016, 11:58 PM

So, this seems to be Windows-specific. It looks like the error is occuring at, which doesn't check the return value of renameTo. When the rename fails (as may occur when dealing with windows file locking), rename returns false and persisting the configuration silently fails.

FileSystemResource.renameTo should really be using rather than just File.rename to rename the file in order for the rename to work on windows.

Torben Barsballe
September 8, 2016, 12:11 AM

Unfortunately, FileSystemResource is in gs-platform and IOUtils is in gs-main (which depends upon gs-platform) so this is a bit more complicated. I feel like IOUtils should perhaps be top level (gs-platform), but it depends on XStreamPersistor, which is also part of gs-main, so I see why it is where it is. Perhaps splitting up IOUtils is the correct route here?

Either way, the IOUtils.rename implementation should be being used wherever we try to rename a file in GeoServer.

Torben Barsballe
September 8, 2016, 10:00 PM

Fixed on 2.9.x by copying IOUtils.rename into FileSystem resource:
Fixed on master by moving IOUtils to gs-platform (see ):

Some argument could be made for changing the behavior of FileSystemResouce.renameTo to actually throw an exception upon error, but this is a substantial API change an is as such unlikely to happen. The GWCConfigPersister class that is responsible for saving the configuration doesn't actually check the return value of renameTo - it looks like it is expecting an exception (I wonder if this behavior changed during the ReosourceStore work?). A breif look at the call heirachy for renameTo suggests that several other calls also ignore the return value (Some do actually check it but it is about 50-50).

Andrea Aime
February 15, 2017, 11:47 AM

Mass closing all resolved issues not modified in the last 4 weeks



Torben Barsballe


Mike Pumphrey



Fix versions

Affects versions