Hi all,
Over the past week I have been working on the hibernate configuration
community module. I wanted to send a quick status update to let people know
where things are at.
So first off my goal here is to get the db backed configuration working with
GeoServer as seamlessly as possible. If there is anything that I learned
from the configuration changeover that happened in 2.0 it is that
backwards compatibility needs to be paramout. So I set out with the goal
that no test cases and no client code should have to change in order to work
with the new catalog and config. Nice in theory :) but in practice some code
does have to change, but that is places where tests or client code make bad
assumptions. But all in all these cases are very few.
In order to verify this I hacked up locally a testing configuration that
allowed me to run all the geoserver integration tests (tests that extend
from GeoServerTestSupport) against the hibernate backed config rather than
the classic in memory one. This was a lot of work to setup but it really
paid off since as you can imagine it fleshed out a lot of bugs with the db
config. And I am happy to report that all the test cases pass!! I also ran
all cite tests successfully.
To get to this point I picked up the hibernate module where Emanuele left it
off and completed the refactor we discussed. The refactor in question was to
come up with a dao interface for the catalog and config and have a single
catalog/config implementation. I took Emanuele's initial work and moved as
much logic out of the daos and into the catalog/config as i could. This was
done for (a) backwards compatibility reasons, to keep the same logic as
before regardless of the dao and for (b) maintainability reasons, to keep
that logic in a single central place.
I also removed any customized beans for hibernate and got around those
issues other ways. Having custom beans for hibernate was problematic in that
it leaked out bean implementation details and creation logic over the
codebase, the worst case being in the xstream persistence and restconfig. So
i opted to make changes to the core beans themselves when needed and
workaround the issues with other methods. Now i am not saying that at some
point we won't need custom hibernate beans but I think it should be a last
ditch effort.
Finally the changes are available in my geoserver github repo:
http://github.com/jdeolive/geoserver/tree/catalog_dao
Now all the above is great but it is only level 0. I am taking a "first make
it work and then make it fast and scalable" approach. With a working
implementation the plan is now to stress test it since the whole point of
using a db backend is to be able to scale up to millions of layers. This
part however will also involve changes to client code since there are many
places in the code that assume the entire catalog lives in memory.
That said I would like to get the current changes committed and possibly
start getting some testing from other devs and those of our users who are
eager and brave.
Thoughts? Comments? Objections?
-Justin
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
