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.

Emanuele Tajariol

Not assigned yet.

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.

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 Store{}s, Resource{}s, Style{}s 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.

The idea has been presented in this R’n’D page *Info beans refactoring .

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

• The metadata \- called \**Info inside GeoServer ** 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.

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.

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.

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

getCatalog () and get{}DATA() 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.

Andrea Aime: Alessio Fabiani Justin Deoliveira: Jody Garnett: Saul Farber: Rob Atkinson:

JIRA Task Email Discussion Wiki Page

R’n’D page *Info beans refactoring