Complete refactoring aiming to code base modularization
Description
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.
Environment
None
100% Done
Activity
codehaus
April 10, 2015 at 4:05 PM
CodeHaus Comment From: cholmes - Time: Wed, 27 Sep 2006 15:07:54 -0500 ---------------------
<p>I think this is basically done? Or at least we have more modern discussions about these ideas. So I'm closing it.</p>
<p>org.vfny.geoserver.wfs and .wms packages isolates their services and operations, code compiles and unit tests run. All demo requests that had success before the code reorganization works as well.
GUI app works too.</p>
codehaus
April 10, 2015 at 4:05 PM
CodeHaus Comment From: groldan - Time: Fri, 18 Mar 2005 06:14:11 -0600 ---------------------
<p>So I'm starting to work on it.
The code tree before this modifications started is tagged as PRE_REFACTOR</p>
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.