Ciao Justin,
please, read below...
-------------------------------------------------------
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Founder - Software Engineer
Via Carignoni 51
55041 Camaiore (LU)
Italy
phone: +39 0584983027
fax: +39 0584983027
mob: +39 333 8128928
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://simboss.blogspot.com/
http://www.linkedin.com/in/simonegiannecchini
-------------------------------------------------------
On Tue, Sep 15, 2009 at 3:21 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:
Hi all,
I took the hibernate catalog for a quick test spin tonight.
First off great work, it is so nice to see this actually taking shape.
Here is my first round of feedback.
From a brief code inspection:
* package org.geoserver.catalog.hibernate
The only issue i see here is quite a bit of duplication with the regular
CatalogImpl class. I wonder if there is any possibly of subclassing, or
factoring out a common super class.
IT would be nice to do so and handle all things like event dispatch,
validation (especially since there is a push to stick more validation
logic directly into the catalog), etc...
This is surely advisable but I am not sure we will be doing it soon,
we tried the shorted path for the moment since I needed both to avoid
to load things and memory as well as to use the db for the config,
therefore we decided to go down the path of replacing the catalog
instead of subclassing or providing patches.
* package org.geoserver.catalog.hibernate.beans
* package org.geoserver.config.hibernate.beans
So it seems most of the InfoImpl objects are subclassed with a hibernate
version. In some cases i notice that the subclass does not really do
anything except for add a serialVerionUID. In some cases it just adds a
getter and setter for id.
I am wondering if we can pull all of this up into the default impl
objects? Or is there another reason why we require a subclass per object?
Thinking mostly about maintainence here, adding new types to the catalog
is already a bit of a pain due to adding the interface, the impl class,
and any decorators needed.
This is actually close to the top of the todolist.
I would like to extract implementation for the beans used by the
geoserver catalog in its own module (i.e its own jar), merge the few
changes that we have made and remove our implementation.
Ideally I would like to be able to refer to the jar produce by this
module inside my persistence xml file. This way we could just provide
people with our beans so that they could use them and refer to them
however they want.
Moreover we should also try to allow people to replace them with their
beans, e.g. JPA annotated beans.
Code aside, i actually ran GeoServer, and it started up nicely. Imported
my styles, and my workspaces. But nothing else. No resources, stores or
layers. I will admit i did not dig in very hard.
Well, it is still in progress so I am expecting bugs (we actually just
found one with layer groups).
Ciao,
Simone.
Once again great work guys.
-Justin
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel