This page last changed on Dec 22, 2010 by etj.

Splitting GeoServer model in its own module

Motivation

A standalone module containing only the model classes would allow other applications to interact with GeoServer through java objects and not through XML representation.

Main actors

We have 2 main areas of concern while dealing with GeoServer objects:

  • The metadata - called Info inside GeoServer (e.g.: the info about a style: StyleInfo class)
  • The data (e.g.: the style itself: Style class)

Strictly bound to these concepts there are

  • The catalog: is the object that retrieves the metadata
  • The Loader: given a description of the data, loads the data itself
  • The Persister: given a description of the data and the data, stores the data in a way that can then be accessed by the loader in subsequent read requests

Current implementation

At the moment the *Info classes expose methods to retrieve the owning catalog:
e.g.:

    in ResourceInfo:

void setCatalog( Catalog catalog );       
Catalog getCatalog();

*Info classes expose as well methods to retrieve the related data:
e.g.:
    in StyleInfo:

Style getStyle() throws IOException;

    in FeatureTypeInfo:

FeatureType getFeatureType() throws IOException;

The default implementations:

public Style getStyle() throws IOException {
        return catalog.getResourcePool().getStyle( this );   
}   

public FeatureType getFeatureType() throws IOException {
        return catalog.getResourcePool().getFeatureType( this );
}

Proposed changes

Note: original batch of proposed changes have been superseded after this discussion in the dev's mailing list; this paragraph' contents have been edited since.

Let's say we want to manipulate *Info with an external application. At the moment, we can exchange information via REST, marshalling and unmarshalling data via XML o JSON documents.

In order to be able to create a java interface with external applications, we need to share the *Info classes, avoiding references to class and procedures not available in such external apps.

At the moment we have this class hierachy:

interface XXXInfo;
class XXXInfoImpl implements XXXInfo;

From each XXX concept, we will extract a superinterface and a superclass that only contain the fields that we want to be made available to the external clients.

We will add these objects:

interface IXXXInfo;
class IXXXInfoImpl implements IXXXInfo;

and the original XXXInfo and XXXInfoImpl will inherit from these new classes:

interface XXXInfo extends IXXXInfo;
class XXXInfoImpl extends IXXXInfoImpl implements XXXInfo;

The logic providing the data instances (e.g.: StyleInfo.getStyle()) will remain in the Info class.

  • Remove the relation to Catalog from the *Info instances** This relation is useless when the *Info instance is used outside GeoServer
    • what do we need this relation for? I mean: can't the Catalog be retrieved in some other way than embedding it into the Info instance?
    • should a GeoServer be able to handle more than one Catalog at one time, so that every Info instance in one catalog can only be referred to objects handled by the same catalog?
    • this modification requires a wide update in all Geoserver code, because it would change the way the catalog instance is retrieved.
  • Remove the methods in *Info objects that return the referred data** This methods are useless when the *Info instance is used outside GeoServer
    • this modification requires a wide update in all Geoserver code, because it would change the way data is accessed.

Once the previous tasks have been performed, the *Info classes can be put in a new maven module.

The aforementioned removals require modifications in GeoServer so that:

  • the Catalog can be accessed anywhere a XXXInfo is used (global singleton or injected bean?);
  • A data loader should be explicitly used to retrieve the data associated to the *Info beans.
Document generated by Confluence on May 14, 2014 23:00