GSIP 4 - Status Interface
Overview
Summary of proposal
Proposed By
[~rgould]
Jody Garnett
Proposal Type
Improvement to existing modules
Assigned to release
tbd
State
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.
Links
JIRA task:
Email discussion:
Other wiki discussions:
Motivations
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).
Proposal
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.
Implementation
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. */ reset(); }
Backwards compatibility issues
None that can be forseen.
Participants
- [~rgould]
- Jody Garnett
Comments ( Hide )
|
|
Justin Deoliveira says:Aug 22, 2006 11:03 ( Permalink ) |
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.