Alessio Fabiani wrote: > The proposal seems quite interesting, and I'm almost for it. > > What is not fully clear to me is how the lazy loading of resources is > handled by the new catalog system. A sort of caching system has been > considered? One of the point of weakness of the actual configuration > system, IMHO, is the loading and maintinment of all the resources into > memory.
I agree with you 100% Alessio. ResourcePool is a bit better than what we had before. All resources are stored in a LRU map, keyed by their config object. When an object gets ejected from the map, its dispose() method is called (well for datastores and coverage readers anyways). Caching of the resoures is not so much the issue imho, rather than how we access resources on startup. Currently on startup every datastore is connected to and every feature type is loaded. It will take a bit of work to make sure everything is loaded lazily. But part of the reason why isolating all resource access is nice is it gives us one place to worry about resource loading. Which I think is the first step toward coming up with something better than what we have today. > > Very good the use of XStream and Hibernate for the persistance layer. > > Cheers, > Alessio. > > On Thu, May 22, 2008 at 3:36 PM, Andrea Aime <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > Justin Deoliveira ha scritto: > > Hi all, > > > > Here is the newest version of the configuration GSIP for your reading > > pleasure. > > > > http://geoserver.org/display/GEOS/GSIP+8+-+New+Configuration+System > > > > Questions/comments/feedback welcome. It would be nice to be able > to vote > > on this in next weeks IRC meeting. > > Resource pool... wondering if we may be served better by a method > like: > > catalog.getResourcePool().getResource(DataStore.class, this); > > and have that method backed by a set of pluggable resource loaders. > The alternative is changing the ResourcePool API any time we need > to cache a new kind of resource. Which may not happen that often, > so it's a good alternative. Just wanted to present the options. > > Finally, reading the document I'm not sure what will become of the > "apply/save" cycle. Is it still there, meaning that the "User Interface" > block contains the xxxConfig objects? > > Cheers > Andrea > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Geoserver-devel mailing list > [email protected] > <mailto:[email protected]> > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > > > > > -- > ------------------------------------------------------- > Eng. Alessio Fabiani > Vice-President /CTO GeoSolutions S.A.S. > Via Carignoni 51 > 55041 Camaiore (LU) > Italy > > phone: +39 0584983027 > fax: +39 0584983027 > mob: +39 349 8227000 > > > http://www.geo-solutions.it > > ------------------------------------------------------- > !DSPAM:4007,48357f61170955219720167! > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > !DSPAM:4007,48357f61170955219720167! > > > ------------------------------------------------------------------------ > > _______________________________________________ > Geoserver-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > > > !DSPAM:4007,48357f61170955219720167! -- Justin Deoliveira The Open Planning Project [EMAIL PROTECTED] ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
