Storing styles and layer groups under a workspace.
Under Discussion, In Progress, Completed, Rejected, Deferred
This proposal continues the move toward having a GeoServer workspace be the container for everything a service needs to be anonymous, allowing for having multiple virtual services within a single geoserver instance.
This proposal is the continuation of the following previously accepted proposals:
- GSIP 44 - Virtual services with workspaces
- GSIP 66 - Workspace Local Services
- GSIP 67 - Workspace Local Settings
Workspace property added to StyleInfo.
Workspace property added to LayerGroupInfo.
New subclass of AccessLimits for styles.
New subclass of AccessLimits for layer groups.
Two methods added to the ResourceAccessManager for the two new access limits classes.
The workspace property added to StyleInfo and LayerGroupInfo is allowed to be code This is unlike stores which must be contained within a workspace. A null workspace specifies that the style / layer group is global, and is "inherited" all workspaces. This is more clearly explained with an example.
Consider two workspaces, "foo" and "bar". And 3 styles "point", "line", and "poly":
- "point" is global, and has no workspace
- "line" references the "foo" workspace
- "poly" references the "bar" workspace
Now consider a global WMS GetCapabilities request, /geoserver/wms?request=GetCapabilities. Global services request contain only global entities, so the resulting document would contain only the "point" style.
Considering the request against the virtual "foo" endpoint, /geoserver/foo.wms?request=GetCapabilities would result in all the global styles, plus the ones local to foo, which includes "point", and "line".
Similarly the request against the "bar" endpoint would contain the styles "point" and "poly".
- A global requests contains global styles and layer groups
- A virtual / workspace request contains all global styles/layer groups plus ones defined local to the workspace
Some further explanation of the handling of workspace local layer groups is required. Since a layer group
is really just a container for a set of layers, and styles, whether or not a layer group can be local is dictated by its contents. Which basically means that in order for a layer group to be local to a workspace, its contents must be local to the same workspace, or global. In other words it is not possible for a layer group to be local to a workspace and access anything outside of that workspace that is not global. Since layers are by definition contained within a workspace this mostly amounts to styles.
Workspace specific styles and layer groups are stored relative to the workspace root rather than the data directory root.
|Breaking ResourceAccessManager api, since there are some depending projects implementing the interface||Added abstract base class for ResourceAccessManagers|
|ResourceAccessManager not being the proper place for workspace local filtering|
|Restconfig, still needs to be updated||Added|
|Better ui, one global workspace drop down to rule them all||Push off as future improvement|
In terms of configuration format, there should be no compatibility issues backwards or forwards. Previous versions of GeoServer run on a configuration with workspace specific styles and layer groups will simply ignore them.