Catalog+DAO split
-----------------
Key: GEOS-3806
URL: http://jira.codehaus.org/browse/GEOS-3806
Project: GeoServer
Issue Type: Improvement
Components: Global, Hibernate catalog
Reporter: Emanuele Tajariol
Assignee: Justin Deoliveira
Fix For: 2.1.x
Attachments: gs_trunk_src.diff
Here's a patch against the current trunk (14002) for the Catalog+DAO splitting (refer to to R'n'D page http://geoserver.org/pages/viewpage.action?pageId=22708796).
This is a step-zero refactoring, aimed at a first split from the Catalog logic and the real data handling.
Most of the code is still bound to the InMemoryCatalogDAO requirements.
The hibernate module is not aligned with these changes yet, so it won't work
until refactored itself. I think some other minor changes will be needed to the
CatalogImpl class in order to make also the hib module work.
The main refactoring has been made on CatalogImpl: it has been split in 2 classes + 1 interface:
- main/src/main/java/org/geoserver/catalog/impl/CatalogImpl.java
- main/src/main/java/org/geoserver/catalog/CatalogDAO.java
- main/src/main/java/org/geoserver/catalog/impl/InMemoryCatalogDAO.java
Some other classes have been involved in the refactoring:
- main/src/main/java/org/geoserver/config/util/XStreamPersister.java
Handled some data that are no longer in CatalogImpl, but in InMemoryCatalogDAO.
- main/src/main/java/org/geoserver/data/CatalogWriter.java
- main/src/main/java/org/geoserver/catalog/util/LegacyCatalogReader.java
Reads and writes data file also handled by XStreamPersister.
While CatalogWriter writes data in the "new" format, LegacyCatalogReader may read both legacy and new format.
- main/src/main/java/org/geoserver/catalog/impl/LayerGroupInfoImpl.java
Added a workaround to be discussed about the resolve() call.
- The current DAO exposes methods for every lookup/search loop in the original CatalogImpl. I
think this is the least DAO interface we need for this step zero refactoring.
- All of the listener logic has been left in the CatalogImpl, and the ModProxy stuff as
well. The DAO's update() methods are aware about the proxying because the
InMemoryCatalogDAO needs it to commit() the changes. This kind of coupling
does not worry me, because having old and new values may be useful also for
other checks at DAO level.
- I split the saved() call in the 2-phase preSave() and postSave() to have a
cleaner flow.
- The default(Name|Work)space logic was a bit too tied with the way it was
handled (null key into a Map). Now data and logic is more explicit in their usage.
- resolve() has been moved into the MemoryDAO. Maybe it should not be its
concern, but rather of the object that is creating the resource (the
XStreamPersister?). This has to be discussed and cleaned up.
This patch compiles and passes all the tests with the web+restconfig profiles
activated.
Waiting for a review.
--
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
-
For more information on JIRA, see: http://www.atlassian.com/software/jira