GSIP 73 - Workspace Local Styles and Layer Groups


Storing styles and layer groups under a workspace.

Proposed By

Justin Deoliveira

Assigned to Release



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:


Quick Info

API Changes


Workspace property added to StyleInfo.

     * The workspace the style is part of, or <code>null</code> if the style is global.
    WorkspaceInfo getWorkspace();

     * Sets the workspace the style is part of.
    void setWorkspace(WorkspaceInfo workspace);


Workspace property added to LayerGroupInfo.

     * The workspace the layer group is part of, or <code>null</code> if the layer group is global.
    WorkspaceInfo getWorkspace();

     * Sets the workspace the layer group is part of.
    void setWorkspace(WorkspaceInfo workspace);


New subclass of AccessLimits for styles.

 * Access limits to a style.
public class StyleAccessLimits extends AccessLimits {

    public StyleAccessLimits(CatalogMode mode) {


New subclass of AccessLimits for layer groups.

 * Access limits to a layer group.

public class LayerGroupAccessLimits extends AccessLimits {

    public LayerGroupAccessLimits(CatalogMode mode) {



Two methods added to the ResourceAccessManager for the two new access limits classes.

     * Returns the access limits for the specified style, or null if there are no limits.
    public StyleAccessLimits getAccessLimits(Authentication user, StyleInfo style);

     * Returns the access limits for the specified layer group, or null if there are no limits.
    public LayerGroupAccessLimits getAccessLimits(Authentication user, LayerGroupInfo layerGroup);

Global vs Local

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".

To summarize:

  1. A global requests contains global styles and layer groups
  2. A virtual / workspace request contains all global styles/layer groups plus ones defined local to the workspace

Behaviour with Layer Groups

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.

Data Directory Changes

Workspace specific styles and layer groups are stored relative to the workspace root rather than the data directory root.




Issue/Concern Resolution
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

Backwards Compatibility

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.


Andrea Aime: +1
Alessio Fabiani: +1
Ben Caradoc-Davies: +1
Gabriel Roldán: +1
Justin Deoliveira: +1
Jody Garnett: +1
Mark Leslie:
Simone Giannecchini:


[Email Discussion|]
[Wiki Page|]

Added by Justin Deoliveira, last edited by Justin Deoliveira on Mar 07, 2012  (view change)
View Attachments (0) Info