Complete refactoring aiming to code base modularization
-------------------------------------------------------
Key: GEOS-312
URL: http://jira.codehaus.org/browse/GEOS-312
Project: GeoServer
Type: Task
Components: WMS, WFS, Struts, Global, DTO, Configuration
Versions: 1.3-rc1
Reporter: Gabriel Roldán
Assigned to: Gabriel Roldán
This is for the long awaited code base refactoring aiming to modularization.
The main intend is to get rid of the current annoying structure driven by a very bad decision on the source code structure and refactore it to be based on specific services, leading to a structure similar to
org.vfny.geoserver.config --> server level configuration
org.vfny.geoserver.data -- all the data services
org.vfny.geoserver.data/config -- all the data
org.vfny.geoserver.wfs --> all wfs specific stuff
org.vfny.geoserver.wms --> all wms specific stuff
It should be a first step in going to a full modularized code base, where services are packaged in
independent jar files and then rolled in as needed.
Some goals of this first iteration are:
- serve as a testbed to figure out what exactly must go in geoserver core and what outside it
- experiment separating service level configuration to its own module.
- aquire feedback about if data config should be in core or outside core. (my position is having
datastore/feature type config at core, and having core providing a registry of configured featuretypes
for services to stick on. This way would be easier to implement WMS nested layers by its own config module,
with WMS specific layer names, pulling data from feature types configured in core)
- decouple request handling from servlet api (i.e. get rid of Request.setHttpServletRequest). As I see it, the servlet
API should be just a facade for the HTTP DCP type, but the rest of the application must have no knowledge of what DCP is being used. I will open a Jira tas for this issue.
- Provide a single entry point for all requests, getting rid of the annoying class hierarchy rooted at AbstractService. There are far
better ways of doing its job, like implementing a chain of responsability pattern. This way we'll be able of providing services as
plugins without the need of having to declare all their operations in web.xml, which they shouldn't be allowed to do anyway. Note that if you still want a servlet mapping for each operation (like in wms/GetMap, etc), you still will be able to (for example, mapping geoserver/dispatcher?SERVICE=WMS&REQUEST=GetMap to /wms/GetMap). This worth its own issue though.
So, as it seems hard to come in with a complete plan beyond the trivial wms/wfs repackaging, I guess we should start a branch for this refactoring after 1.3.0-beta is out, and start experimenting on it, using this issue for further discussion. So please post your comments/thoughts here.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira