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.

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.

This package is NOT API and should not be reference from outside this module.

The package contains the implementations that access/control the preferences

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 ).

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.

Sequence of method calls triggered by a GetPreference request

Sequence of method calls triggered by a SetPreference request

Sequence of method calls triggered by a SetDefault request

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.