Hi Allessio,
Yes, the configuration system needs to be redone imho. For the first release of 1.4.x we are leaving it as is as its kind out of scope. Once we get things refactored into a cleaner module system, we can actually start talking about cleaning up configuration as an attainable goal.
I dont want to step on the toes or discourage the people who wrote the current system. Because it works, and works darn good.
Further comments in line.
Alessio Fabiani wrote:
Speaking about the new release of GeoServer and the use of Spring, we should
start thinking on a new configuration system of GeoServer. At least two
aspects should be considered:
1 - The GeoServer active context should be persisted somewhere and GeoServer
should have the possibility to read Stores, Features and Coverages metadata
from the storage instead of having all things in memory. A reading cache
algorithm could be implemented too obviously. For instance Spring could be a
good solution using JDO to persist Beans.
I would like to see an embedded database used (perhaps hsql). I am not that familiar with the JDO spec but I am all for going with a standard for persistence. Here is an article linking the two up. I gave it a quick once over, not sure if it is any good.
http://www.informit.com/articles/article.asp?p=212397&rl=1
Spring also seems to have a lot of good support for JDO just like Hibernate. Hibernate of course could be another option.
However as a developer writing a geoserver plugin, I want to be hidden from all this and have my POJO's persisted by GeoServer, how its being done should really be hidden from me. Of course unless I want to get into things like Transactions and such, no promises there :).
2 - The actual Data Configuration system is too hard to use. In the WCS
experiment in order to be less invasive as possible I added the possibility
to create CoverageStores and FeaturesStores and then create Coverages and
FeatureTypes from them... In a future relase I would like to see a unique
DataStore and a unique way to obtain Data from the latter giving to the user
the feeling that the catalog is unique for all kind of Data. This issue has
to be considered in an optic of having separate modules. What I would like
to avoid is to have a different configration for each new module I add.
Agreed. I need to look at what you are guys are up to on wcs-branch. I plan to checkout the branch so I can at least talk intelligently about what is going on. I would like to face the issue of merging you guys back in sooner rather then later. And with all the 1.4.x re modularizing going now might just be the best time to do it.
I know that you guys are working off of geotools trunk correct? A worth while experiment would see how much work it is to get 1.4.x onto trunk as its on 2.2.x right now. I think dave may have looked into this. My impression from what has been going is not a lot. I think the biggest change is the Expression api changeover, and that was done to keep thing totally backwards compatible.
Cheers,
Alessio.
--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com
