On Tue, Jan 15, 2013 at 11:28 PM, Justin Deoliveira <[email protected]>wrote:
> Hey folks, > > I wanted to run some proposed refactoring of the ResourcePool class past > everyone. Basically my goal is two-fold. The first and primary goal is to > extend to the jdbcconfig module to allow for storing SLD contents along > with configured style objects. It is really the last step to make the > module able to store all catalog contents in the database. > > The idea would be to make it possible to plug in a custom ResourcePool > implementation via spring. The lookup mechanism is similar to how others > work in that first we would look for an instance in the spring context, and > if not found fall back to the default implementation. > > A secondary goal is to allow for implementations to control how the > various caches in ResourcePool are created. One thing I have been wanting > to experiment with is the idea of distributed caches that GeoServers in a > cluster could potentially share. This secondary goal is not an immediate > one but I figured since i was mucking around in the vicinity i would make > these changes as well. > > All in all the changes are pretty straight forward, and mostly a pure > refactoring with no behavioural changes. > > > https://github.com/jdeolive/geoserver/commit/2dd214507cd764486707ed93711f380ff4db0f71 > > Thoughts or opinions? Do people feel this is something proposal worthy? I > should note that i was hoping to do this on 2.3.x. > I'm good with the refactor allowing to change the resource pool, it is useful in general as people might want to perform caching of resources their own way. I agree that implementation wise this can be used to store styles somewhere else, but styles are not the only thing that should be stored in the database if you want a centralized configuration. How about freemarker templates, override xsd schemas, the security subsytem configuration, or the configurations for the extension modules, the files in the www directory ... and I'm probably forgetting something else too. It seems to me we'd need something different, like a ResourceFileAccessor of some kind, or some extension to the catalog facade so that no direct access to the data directory file system is ever made, possibly with events so that code can listen to direct changes to the data dir contents. Hmmm... and GWC won't play good with that either, as the configuration code there also assumes it can access a file system. Cheers Andrea -- == Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it -------------------------------------------------------
------------------------------------------------------------------------------ Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612
_______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
