GeoServer

Contains all interface servlets, one for each WFS response.

This appears out of date. Appears to have tomcat and execption handling 12/17/03 dz.

GeoServer Exception revolves around the ability of ServiceException to turn itself into a propert XML response document.

We have chosen to embed a version of Tomcat to provide an easier setup process for new users.

All GeoServer STRUTS Actions should be branched off of GeoServerAction which provides authentication for the configuration system.

In the future we may wish to rethink this policy of other subsystems beside configuration start to make use of the STRUTS framework.

All GeoServer STRUTS Actions should be branched off of GeoServerAction which provides authentication for the configuration system.

In the future we may wish to rethink this policy of other subsystems beside configuration start to make use of the STRUTS framework.

All GeoServer STRUTS Actions should be branched off of GeoServerAction which provides authentication for the configuration system.

In the future we may wish to rethink this policy of other subsystems beside configuration start to make use of the STRUTS framework.

Contains Actions for configuring the GeoServer Web Map Server.

All GeoServer STRUTS Actions should be branched off of GeoServerAction which provides authentication for the configuration system.

In the future we may wish to rethink this policy of other subsystems beside configuration start to make use of the STRUTS framework.

This class opperates as the Configuration Model and is stored in Web Container.

• Represents the Model of the STRUTS based Model-View-Controller Design
• Will support additional user-interface state, beyond requirements of the GeoServer application.
• Makes use of GeoTools2 Catalog/DataStore for FeatureType type names and FeatureType schema information/generation.
• To access live content, use the DataConfig.findDataStore()

Of the course of sorting this stuff out we have had a couple of bad ideas:

• It is tempting to replace a lot of these classes by changing the scope of the FormBeans to session, rather than request. I cannot convince my self that this would be a good idea, as storing the configuration model (and associated resources in the Web Container) is sure to prevent duplication in the face of multiple users configuring differnt subsystems. If the state was limited to session - they would manage to overwrite each other with no prior warning.
• It is tempting to make the Actions use the DTO objects directly (or forgo the config classes entierly). Having the config classes allows us to make whatever methods we need for easy, quick ui developement without breaking the rest of the application.

This class opperates as the Validation Model and is stored in Web Container.

• Represents the Model of the STRUTS based Model-View-Controller Design
• Will support additional user-interface state, beyond requirements of the GeoServer Validation application.
• Makes use of GeoTools2 and Vivid.

Of the course of sorting this stuff out we have had a couple of bad ideas:

• It is tempting to replace a lot of these classes by changing the scope of the FormBeans to session, rather than request. I cannot convince my self that this would be a good idea, as storing the configuration model (and associated resources in the Web Container) is sure to prevent duplication in the face of multiple users configuring differnt subsystems. If the state was limited to session - they would manage to overwrite each other with no prior warning.
• It is tempting to make the Actions use the DTO objects directly (or forgo the config classes entierly). Having the config classes allows us to make whatever methods we need for easy, quick ui developement without breaking the rest of the application.

FormBeans are used to communicate the state of the view to/from the Model.

Capabilites:

• FormBeans are derived from ActionForm
• FormBeans have a validate method for simple sanity checks
• FormBeans have a reset method which we will use to aquire the model state for editing by the user

Contains Form Beans describing the GeoServer Data Model.

FormBeans should be derived from ActionForm. FormBeans are used to communicate the state of the view to/from the Model. They hold the validate method which should do some basic sanity checks. Actually testing that the model works should be left to the config package.

Contains Web Feature Server Form Beans.

FormBeans should be derived from ActionForm. FormBeans are used to communicate the state of the view to/from the Model. They hold the validate method which should do some basic sanity checks. Actually testing that the model works should be left to the config package.

Contains Web Feature Server Form Beans.

FormBeans should be derived from ActionForm. FormBeans are used to communicate the state of the view to/from the Model. They hold the validate method which should do some basic sanity checks. Actually testing that the model works should be left to the config package.

Contains Web Map Server Form Beans.

FormBeans should be derived from ActionForm. FormBeans are used to communicate the state of the view to/from the Model. They hold the validate method which should do some basic sanity checks. Actually testing that the model works should be left to the config package.

In the future we may wish to rethink this policy of other subsystems beside configuration start to make use of the STRUTS framework.

Common state used by the GeoServer Servlets is maintained by this package.

• Contains the actual server state - that is WMS reflects the state of the Web Map Server
• These classes should be saved in the Web Container (rather than the current singletons)
• Application set up is provided using Data Transfer Objects from the global.dto package. Both the initial loading the initial XML configuration files and the dynamic configuraiton systems are handled in this manner.
• Data contains "real" GeoTools2 DataStores with JDBC connections (and implements the GeoTools2 Catalog Interface)

GeoServer State Diagram

We would like to bootstrap this process using the STRUTS plug-in interface and store the GeoServer application state in the Web Container. Currently this information is accessed by a singleton, and bootstraped by the first GeoServer servlet request (JG - I think ).

Application set up is provided using Data Transfer Objects from this package. Both the initial loading the initial XML configuration files and the dynamic configuraiton systems are handled using these objects.

The use of Data Transfer Objects allows the Global package to not depend on either the Persistence Method (some DataStore configuration infromation may migrate from XML into the Database) or the Dyanmic Configuration System.

If GeoServer moved to a JXM scheme for management the DTO object will be used "over the wire".

This package is the XML Persistence Subsystem. It contains methods to read and write the GeoServer configuration files based on the global.dto objects.

The use of Data Transfer Objects allows the XML Persistence package to not depend on Global Method or the Dyanmic Configuration System. In fact we could make use of this separation to back the configuration system directly onto the xml files (without geoserver) if needed.

Servelets in the WFS and WMS package contains all interface servlets, one for each WFS response.

• Is built around Servlets derived from AbstractService
• ActionService subclasses provide a mapping of Handler, Request, and Response

Generally speaking, all of the response logic that does not tie directly to a data storage format can be found here.

Response is part of the Handler/Request/Response trinity requred by AbstractService.

This workflow can be somewhat hard to understand from the Source Code of AbstractService - it makes use of a series of Stratagy objects to allow you to fine tune your applications performance while maintaing the above contract with Response.

This package contains both the Handlers and the Request objects. Request Objects seem to act as a Data Transfer Object between the Handlers (which parse the client's request), and the Response (which executes their request, and formulates a response document).

These classes are instnaces of KvpRequestReader or XmlRequestReader and are used by the GeoServer handlers to parse information into Request Objects.

There is one Servelet for each Web Feature Server response. These servlets should extend WFSService and provide the mapping of Handler, Request and Response required for the Service.

GetCapabilities seems to be located in the response package right now.

There is one Servelet for each Web Map Server response. These servlets should extend WMSService and provide the mapping of Handler, Request and Response required for the Service.