Storing server settings per workspace.
Under Discussion, In Progress, Completed, Rejected, Deferred
This proposal is the next iteration of having GeoServer support "multi tenancy", the ability to have multiple "virtual servers" reside in one physical server. To achieve this one must be able to configure each virtual server independently.
This proposal is an extension of the two previously completed proposals:
The first proposal laid most of the groundwork in order to make use of workspace as the virtual services mechanism. The second added the ability to configure OGC services differently per worksapce / virtual service. This proposal allows for configuring other "global" settings per workspace.
The current patch is available here.
The GeoServerInfo interface encompasses what are referred to as "global geoserver settings". This includes things like logging configuration, JAI settings, server proxy url, etc... Its properties can be organized into two groups.
- those that are truly global, including:
- coverage access
- admin username/password
- update sequence
- feature type cache size
- xml post request log buffer size
- global services flag
- those that could be made specific to a virtual service, including:
- contact information
- number of decimals
- verbose and verbose exceptions
- proxy base url
- schema base url
- online resource
A new interface, named SettingsInfo is introduced to encapsulate the second set of properties.
The GeoServerInfo interface now has a "settings" property. All properties moved to the new interface are deprecated.
A new method getSettings() is added to the GeoServer facade. Along with some new methods for adding,saving, and removing a SettingsInfo instance.
The get settings method uses the same thread local instance, LocalWorkspace, in order to choose the correct settings based on the current virtual service.
It is important that all client code call GeoServer.getSettings(), and not GeoServerInfo.getSettings() in order to obtain the correct settings based on the local workspace / virtual service. The latter method will always return the true global settings.
Workspace specific settings are stored in the workspace directory in a file named settings.xml
No settings.xml is introduced at the top level, rather the settings are serialized "inline" in the existing global.xml file. The contents of global.xml change from:
Workspace local settings are enabled from the edit page for the workspace.
When enabled, a copy of the global settings are made and stored local to the workspace.
This section should contain feedback provided by PSC members who may have a problem with the proposal.
The configuration changes are backward compatible but not forward compatible as the global.xml format is changed.