This activity completes the transition to the ResourceStore API. See examples for the kind of changes covered here.

This work is ongoing, Niels will have a pull request.

The following file references will be maintained:

• Log Files
• GeoWebCache directory
• File upload
• Spatial data (shapefiles, geotiff, h2 databases)
• Default H2 databases (default for JDBCConfig, Embedded GeoFence, Monitor Extension)

When using a ResourceStore access to the GEOSERVER_DATA_DIRECTORY is no longer required, and can instead be used as a "cache" of ResourceStore content.

This value is supplied by GeoServerResourceLoader#lookupGeoServerDataDirectory(ServletContext) is where this location is defined.

It is obtained twice:

• During logging to locate the GEOSERVER_DATA_DIRECTORY/log folder and obtain the logging profile used during startup, and the location of the geoserver.log file.
• During DataDirectoryResourceStore creation as the location of the "base directory"

This value is published in several locations, we need to ensure that GeoServerResourceLoader.getBaseDirectory() is safe to use (and does not unpack all files).

• Inject the value?
• Delegate to ResourceStore.getBaseDirectory() - this would require each implementation to use lookupGeoServerDataDirectory(ServletContext) during application init.
  • The FileSystemResourceStore(DataDirectorResourceStore) is already doing this.
  • The JDBCResourceStore has access to the FileSystemResourceStore, so need not do this itself.
• Could GeoServerResourceLoader call lookupGeoServerDataDirectory during its lifecycle? yes

During normal application use:

• This is called by the user interface - to provide a location for the file chooser (see GeoServerFileChooser).
• To display on the status page

During testing:

• A lot of tests - this is not a problem as they all use FileSystemResourceStore
• Sometimes via GeoServerDataDirectory.root()