Also in case you missed the email i sent a couple of weeks ago i did
acutally try to summarize the main parts of the patch. Here it is just in
case:
So the patch as you can imagine is rather large. But I will summarize the
main points of it here:
1. CatalogDAO and GeoServer DAO interfaces created, with DefaultCatalogDAO
and DefaultGeoServerDAO as default implementations respectively
2. Data access code factored out of CatalogImpl and GeoServerImpl and put
into the default daos
3. Some minor catalog/config bean tweaks, implementing equals()/hashcode(),
adding default constructors, etc...
4. GeoServerLoader refactored to allow for subclasses to override startup
loading behaviour. GeoServerLoaderProxy is not registered with spring and
loads a GeoServerLoader
instance based on the spring configuration, falling back on
DefaultGeoServerLoader which implements the default startup we have today
5. XStreamPersister modified to handle different implementations of List,
Set, etc... For instance in cases such as hibernate that creates custom
collections. It know is lax and
simply works against the Collection interfaces not worrying about
specific implementations of a collection
6. GeoServerTestSupport modified to reflect the changes made to
GeoServerLoader
7. GeoServerImplTest and CatalogImplTest modified to allow for subclases.
Also removed some bad assumptions that assumed an in memory implementation
of the catalog/config
On Tue, Oct 19, 2010 at 9:45 AM, Andrea Aime
<[email protected]>wrote:
> On Tue, Oct 19, 2010 at 3:54 PM, Justin Deoliveira <[email protected]>
> wrote:
> > Hi all,
> > I am not sure if i made it clear when i posted the GSIP last week but i
> > would like to move it forward through voting. So far I have no votes on
> this
> > proposal from any PSC members.
>
> Hey there... sorry for not replying, I did not do because I did not find
> an easy to review the proposal, so I guessed I had to actually read the
> patch
> line by line to figure it out.
>
> I see the new interfaces (one is without javadoc comments btw) and I had
> a quick look at the code but the structure of the changes escapes me when
> just glancing at the code.
> (btw, why is every access to the DAO synchronized inside the catalog,
> would it be the same
> to have the dao implementor synchronize every method if the dao is
> not thread safe?)
>
> I won't have time to really look into the diffs until next weekend, I
> guess having
> a bit more of description would expedite the review (things like the
> dao synch above for example).
> You know, something that sits in the middle between "let's have a DAO
> approach"
> and actually going line by line through the patch.
>
> But if you can wait till the weekend I can actually sit down head
> clear and look into
> it for good as is, without any change or extra description.
>
> Cheers
> Andrea
>
> -----------------------------------------------------
> Ing. Andrea Aime
> Senior Software Engineer
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> Italy
>
> phone: +39 0584962313
> fax: +39 0584962313
>
> http://www.geo-solutions.it
> http://geo-solutions.blogspot.com/
> http://www.linkedin.com/in/andreaaime
> http://twitter.com/geowolf
>
> -----------------------------------------------------
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
