This page last changed on Jan 27, 2012 by cholmes.

Overview

Moving the Geoserver catalog *Info beans into a standalone module.
Removing methods and references from these beans referring to classes, data and logic that would be useless in external applications that could use the bean definitions but not share GeoServer internal data.

Proposed By

Emanuele Tajariol

Assigned to Release

Not assigned yet.

State

Under Writing, Under Discussion, In Progress, Completed, Rejected, Deferred

This proposal never got off the ground, and internals have probably changed enough that it should be reworked if the sentiment is desired.

Motivation

At the moment, when an external app needs to exchange data with a GeoServer instance (e.g.: via REST or by accessing a DB-based catalog), it has to re-define its own set of beans representing Stores, Resources, Styles and so on.

It could be extremely handy if external applications could use the very same *Info beans used by GeoServer (both interfaces and related implementations).

In the present architecture this cannot be accomplished without importing in the external app all the catalog logic, that is useless outside a complete GeoServer instance.

All in all, this refactoring will make clear the boundaries of metadata objects, making the creation of modules for marshalling/umarshalling them much simpler.

Proposal

The idea has been presented in this R'n'D page.

Introduction

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: the real objects that GeoServer uses in its services (e.g.: the style itself: Style class)

What we want to do is to isolate the metadata beans from the other objects; that's because an external app can only deal with this kind of info about the GeoServer objects, while the data itself may be not accessible at all to it.

Removing metadata-catalog relation

Most of the metadata objects keep a relation to the originating catalog.

e.g.:

    in ResourceInfo:

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

Since a catalog object could not be properly handled outside a GS instance, it should not be referenced by a refactored bean.

This means we need an alternative way to retrieve the current catalog. Since the main Catalog implementations (a "raw" catalog and a secured instance) are injected via Spring as singletons, we may just refer to these global instances.

Removing metadata-data relation

Metadata classes also expose 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 );
}

Here we should split the concept of a data loader from the metadata itself. This split helps our refactoring, and underlines a clean separation of concerns.

Instead of having something of this kind:

FeatureTypeInfo fti = ...
FeatureType ft = fti.getFeatureType();

we'll end up having:

ResourceLoader resourceLoader = ...
FeatureTypeInfo fti = ...
FeatureType ft = resourceLoader.load(fti);

Once these steps are done, the *Info and *InfoImpl classes can be easily moved into another module.

Feedback

Thread in Geoserver-devel: GSIP 45 - Moving GeoServer model in a standalone module

Backwards Compatibility

getCatalog() and getDATA() will be removed from all the Info beans; this implies a lot of GeoServer code will be updated following this refactoring.

However, a complete patch will be provided in order to make GeoServer and the extension modules build properly.

Voting

Andrea Aime:
Alessio Fabiani
Justin Deoliveira:
Jody Garnett:
[~sfarber]:
[~roba]:

Links

[JIRA Task|]
[Email Discussion|]
[Wiki Page|]

R'n'D page

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