This page last changed on Jan 09, 2007 by jive.


Summary of proposal

Proposed By

Jody Garnett

Proposal Type

Improvement to existing modules

Assigned to release



Interface was created in the community module, wrappers produced for core components. Expect work to be picked up formally by GeoServer developer community when LGPL core formally defined.


JIRA task:

Email discussion:

Other wiki discussions:


A mechanism is needed to inform a client application if all of the modules in a particular GeoServer instance are available and working properly. A specialized module can communicate with other modules in GeoServer to check their configuration status.

Example use case:
Client application starts and immediately connects to the server. It checks to see if all of the required modules have started and are available. If not, the client can either abort or it can attempt to perform some other action (such as re-configuring the server).


The only impact this will have on the existing GeoServer modules is that they can implement the Status interface, but they are not required to. The communciating module will be tolerant and will operate only against modules that implement this interface.

The hard part is defining "status" for a module. For now, we will only consider whether a module has been started or not. Each module that implements the Status interface should be able to report an error when one occurs.


A new module will be created that can be queried with Spring remoting from the client. This module will communicate with each of the modules that implement the Status interface (see below) and will forward the responses back to the querying client.

/** To be implemented by each module taking part of startup */
interface Status {
    getStatus(): enum { OK, WARNING, ERROR }
    getError(): Throwable

 * Interface used to interact with GeoServer module system from a remote client.
interface Modules {
    /** Status of each module in start up order. */
    List<Status> getStatusList();

    * Reset GeoServer modules, called change to configuration and/or preferences.
    * Modules with handles to real resources should be implemented in a smart manner, so as not to recreate connection pools etc.

Backwards compatibility issues

None that can be forseen.


This seems to be the mix of two concepts 1. Remote component management, 2. Component lifecycle . I am weary about rolling our own system as JMX solves 1, and a good plugin framework ( OSGi? ) solves 2. I think someone really needs to do the reasearch of spring and jmx because the support for it in spring looks complete.

However I am not against. But I would like to recommend the following changes. Instead of having geoserver components implement these interfaces, make them wrapper classes. That way no geoserver code has to depend on them. So if we do want to swap them out at some point with something else it is painless.

Posted by jdeolive at Aug 22, 2006 11:03

Because we do not need to do remote manipulation of data, we do not need to use JMX. We are only currently interested in the status reports from the modules. I will make the change to wrapper classes rather than interfaces.

Posted by rgould at Aug 23, 2006 16:57
Document generated by Confluence on May 14, 2014 23:00