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 <[email protected]> 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
