GeoServer : GSIP 8 - New Configuration System
This page last changed on Nov 08, 2010 by simboss.
Adding a new configuration subsystem that is easier to maintain and more effective then the one currently in place.
Core Module Change
JIRA task: http://jira.codehaus.org/browse/GEOS-1951
Email discussion: http://www.nabble.com/new-configuration-gsip-reworked-td17379978.html
Other wiki discussions:
The current configuration is cumbersome for programmers. A simple change to a configuration parameter can require the changing of up to 3 classes. Furthermore, each "config object" is duplicated with a "data transfer object" which is used to capture its properties" during persistence.
Furthermore the current config objects have become somewhat messy. Coming up with an api which is more "bean like", and consistent in terms of naming conventions for properties will produce a nicer api to work with.
Implementing the new configuration falls into 3 primary phases:
This phase is more or less complete. An in depth description of the new model can be found here:
The new configuration model is inspired by the old model, and the core classes or more less the same. Wrapping up the new model objects in the old objects is straight forward. The main benefit of such an approach is that it remains backwards compatible with the rest of GeoServer. This allows us to keep the user interface, persistence layer, and services all untouched.
The following diagram illustrates the way things currently work today:
The following diagram illustrates the proposed changes. Essentially ripping out the internals of the "global" tier and replacing it with the new model.
At the code level the work boils down to removing all properties from the old config objects and having all methods call though to associated new objects. For example, consider the following subset of the FeatureTypeInfo object.
This process is repeated for all config objects. The following mappings are made:
This phase involves porting the rest of the code base to the new model. This involves services and the ui. At this point the persistence model can be swapped out by one that is easier to maintain and which automatically persists the configuration beans.
See the following page for details:
As described in the previous section
In the old configuration model, the "info" objects are responsible for loading resources like geotools datastores, feature types, coverage readers, and styles. For an example see FeatureTypeInfo.getFeatureSource(). This poses a number of difficulties:
For this reason a class dedicated to loading resources is created called ResourcePool. It seperates all the source handling code away from the configuration beans. Consider DataStoreInfo:
The ResourcePool object is a singleton, and stays around for the life of the GeoServer instance.
On system startup and on subsequent configuration loads the configuration stored on disk must be read into an instance of the new model. The following classes have been added:
Reads the services.xml, catalog.xml and info.xml files into instances of the new model. In GeoServer 2.x when we change the persistence layer these classes will be used as a utility to support loading of GeoServer 1.x configurations.
Runs on startup and delegates to the above two classes to initialize the configuration system. This class also has a shutdown hook which will be used to persist the configuration system when the persistence layer is changed.
An extension point for loading service configurations. This allows the core configuration system to not have to know about services which have been plugged in. There are currently three implements: WFSLoader, WMSLoader, and WCSLoader.
An extension point interface uses to initialize based on GeoServer configuration. This extension point is processed by GeoServerLoader after the configuration is read. See the next section about Logging and JAI initialization.
In the current system initializing of these sub systems occurs in static methods on org.vfny.geoserver.GeoServer. IN the new model this class is a strict java bean so this type of system initialization is out of place. The equivalent has been implemented as instances of the GeoServerInitializer extension point. These implementations use the new configuration system event model to keep in sync when users change configuration via the user interface.
This type of core change of course has the potential for a number of regressions. The best way to address this is rigorous testing.
Passing of all existing unit tests without making any changes to the unit tests themselves.
Extensive hand testing of the user interface. This involves testing the change, saving, and reloading of every single configuration option in the user interface (painful i know).
|Document generated by Confluence on May 14, 2014 23:00|