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.
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 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.
The idea has been presented in this R'n'D page.
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.
Most of the metadata objects keep a relation to the originating catalog.
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:
The default implementations:
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:
we'll end up having:
Once these steps are done, the *Info and *InfoImpl classes can be easily moved into another module.
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.