This page last changed on May 10, 2007 by jdeolive.


A key aspect of GeoServer configuration is of course persisting it between GeoServer runs. The current GeoServer configuration does this just fine however has a few issues with it.

The first is that every time a new parameter or object is added to the configuration the xml reader and writer must be modified to support the new parameter / object. What would be ideal is to have the configuration file reader / writer dynamically read and write configuration parameters so that adding a new parameter is as easy as adding a property to a java class.

A second issue is the lack of an interface to allow for the use of different persistence mediums. For instance, currently GeoServer uses files to store all configuration. However a user may wish to store configuration in a relational database. Ideally the persistence medium is something that can be plugged in without affecting the rest of GeoServer.


Developers often modify the configuration system for a number of reasons. The following examples illustrate some of the common cases.

Example 1: 8 bit PNG

Consider someone trying to support 8 bit png images in GeoServer. Since an 8 bit png vs a 24 bit png results in a lower quality image this is probably something that we want the end user to be able to control. So ideally the developer will want to add a flag to the WMS configuration to toggle between 8 bit and 24 bit pngs. This is an example of a developer needing to add a configuration parameter in order to control the behavior of a service.

In the current GeoServer configuration system to add a single parameter requires the editing of at a minimum of 5 files:

  1. xml reader
  2. xml writer
  3. dto
  4. config
  5. global

If the parameter is to be made accessible via the ui this numbers goes up by 3:

  1. action
  2. form
  3. jsp

Ideally we would like a single point of modification and have it propagate automatically. The current amount of work to add a new configuration parameters hinders developers to do so.

Example 2: Web Processing Service

Consider someone implementing a Web Processing Service (WPS) in GeoServer. The WPS will need to be able to store data about the processes that it makes available. Ideally this new type of data, lets call it a process , will be a first class citizen of the configuration system just like coverages, and feature types are today. This is an example of a developer having the need to add new types of objects to the configuration system.

While adding new types of objects to the configuration is possible, it is not an easy task. Take into consideration the adding of coverages to the configuration. Much of the code is copied from feature type configuration. What is needed is a true api that is meant for extensibility which defines good base classes to subclass, etc..

Example 3: Topology

Consider someone wanting to implement topology support in GeoServer. This will require the developer to add a new type of resource, a topology, to the configuration system. However the developer does not wish to add a new service to GeoServer and wants to use WFS to serve up topologies via GML. Since WFS only deals with feature types the developer needs to be able to "adapt" a topology instance into a feature type. This is an example of a developer needing to "adapt" an existing object in the configuration into another type of object.

This pattern is somewhat well known as the "adapter pattern" and is not supported by our current configuration. However it proves to be a very powerful pattern when applied properly as it allows developers to add new types of objects to a system without the system having to know about it.

Backward and Forward Compatibility

Having an extensible configuration system is nice but care must be taken to ensure backwards compatibility when changes are made to it. When a new parameter or object is added to the configuration the underlying file or database it is stored in changes in structure. What happens when you try to run the newly structured configuration with an older version of GeoServer? What happens when you run an old configuration with a newer version of GeoServer?

Putting the burden on users to upgrade every time the configuration is changes is unaccetpable. Making a new major release every time configuration changes is also unacceptable. For this reason the configuration system must take care when reading from persistence. Handling the cases of when an unrecognized parameter or object is found (forward compatibility), and when a parameter or object is missing (backward compatibility).


Scalability is a crucial aspect of any production system. Again let us use a series of examples to illustrate.

Example 1: Large Number of Datasets

A user needs to publish 1000's of datasets through GeoServer without paying 1000's of dollars for expensive hardware and a ton of memory.

The current configuration system will not scale in this manner. The entire configuration is read into memory on startup instead of being lazily loaded.

Example 2: Clustering and Load Balancing

A user needs to be able to serve 1000's of users simultaneously and wishes to set up a cluster of GeoServer's in order to load balance. Furthermore the user does want to go through the hassle of maintaining the configuration of every node in the cluster in isolation and wants a central place to manage configuration.

This is currently no easy way to achieve this with GeoServer as it relies on the configuration files being stored on a local disk.

Example 3: Redundancy

A user wants to set up a fault-tolerant system made up of redundant servers in which one will kick in if another goes down. As with example 2 there is no easy way to achieve this while configuration is stored locally.

Remote Access

A common request from users is the ability to modify the GeoServer configuration programtically, and more often then not remotely. Consider someone trying to implement an "ingestion engine" for GeoServer in which some process continuously monitors a location, be it a directory on disk, or a database. When data is added the engine will automatically "ingest" the data and update the GeoServer configuration accordingly. Ideally this is achieved through some sort of RPC call, be it XMLRPC, a simple http request, etc...

While possible to do with the current configuration system, the approach is very much a hack which involves modifying the configuration files in place and then programatically logging into the web application and using the web ui to reload the catalog. A nicer api is very much needed.

Third Party Tools

For some users a remote access api is not enough and they require the ability to hack the configuration directly Ideally the GeoServer configuration is stored in well-known format which is accessible to wide variety of environments and tools. Storing the configuration in a way in which it is accessible through some sort of standard such as XML or JDBC is a must.

Document generated by Confluence on May 14, 2014 23:00