On a new GeoServer install:
Go to Caching Defaults page
Check "Direct Integration"
Go to Welcome Page
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
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 http://demo.geo-solutions.it/geoserver/ which is the current day's nightly build, and checking the changes via the resources REST api, e.g., "http://demo.geo-solutions.it/geoserver/rest/resource/gwc-gs.xml", 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?
So, this seems to be Windows-specific. It looks like the error is occuring at https://github.com/geoserver/geoserver/blob/master/src/gwc/src/main/java/org/geoserver/gwc/config/GWCConfigPersister.java#L111, 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 https://github.com/geoserver/geoserver/blob/bf0345d228111c15aeff6f7c1bc87b4ed230af96/src/main/src/main/java/org/geoserver/data/util/IOUtils.java#L485 rather than just File.rename to rename the file in order for the rename to work on windows.
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.
Fixed on 2.9.x by copying IOUtils.rename into FileSystem resource: https://github.com/geoserver/geoserver/pull/1813
Fixed on master by moving IOUtils to gs-platform (see ): https://github.com/geoserver/geoserver/pull/1812
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).
Mass closing all resolved issues not modified in the last 4 weeks