Pluggable BlobStores

Introduction

BlobStore is the interface that handles the actual storage and retrieval of tile images. The only realization is currently FileBlobStore, which stores tiles as single files following a legacy filesystem layout.

There can be one single instance of FileBlobStore and the location of the stored tiles is tied to the location of the geowebcache.xml configuration file.

This proposal aims to incorporate the following enhancements while maintaining behavioral backwards compatibility with GWC versions prior to 1.8, and minimal API changes:

• Decouple the location of the cache directory and the geowebcache.xml configuration file;
• Allow for multiple cache base directories;
• Allow for alternate storage mechanisms than the current FileBlobStore;
• Allow for different storage mechanisms to coexist;
• Allow to chose which "blob store" to save tiles to on a per "tile layer" basis.

Status

Work is being conducted on groldan's pluggable_blobstores branch.

Code is almost complete pending more unit tests for the new functionality and documentation.

See the full set of changes.

Strategy

Given BlobStore is an interface, we can obviously create implementations that store tiles in a different format and/or storage backend. Problem is GWC is designed to work with only one, defined in the Spring configuration. The easiest path forward to have multiple BlobStores coexisting is to keep that assumption but use a composite blob store instead, that merely multiplexes tile operations to the actual blobstores configured in the geowebcache.xml configuration file. This gives the flexibility necessary for the administrator to easily configure several blob stores without messing with the spring configuration.

To do so, instead of changing BlobStores API, we'll define a base configuration bean that defines the basic properties (unique id, enabled flag, etc) of a blob store, and concrete subclasses specialized in configuring and creating instances of different blob store types.

With this in place, the only missing piece to glue everything together is TileLayer's ability to define which blob store its tiles shall be stored to, so adding a blobStoreId property to TileLayer. This property can be undefined (i.e. null), meaning the "default" blob store shall be used instead. The "deafult" blob store is by default the same FileBlobStore than for versions prior to 1.8, and created automatically following the same cache directory lookup mechanism. But it can also be overridden by configuring a blob store in geowebcache.xml and settings its boolean default flag to true.

Changes

Add getBlobStoreId():String method to TileLayer, allow it to return null, meaning its tiles are handled by the default blob store.

/**
 * @return the identifier for the blob store that manages this layer tiles,
 *         or {@code null} if the default blob store shall be used
 */
public String getBlobStoreId();