Hi Andrea, as long as it works and it's clear how to disable (at least for testing without it) I'm ok with your proposal getting into both 2.1.x and 2.2.x _now_, taking into account for 2.2.x we'll hopefully come up with a solution more general/less invasive, or whatever QA requirement we assess we need to push for to enable scalability and HA.
Cheers! Gabriel On Wed, Nov 9, 2011 at 1:29 PM, Andrea Aime <[email protected]> wrote: >> Missed this the first time around :) While not ideal I think this will be >> the best approach for now (keep it constrained) until funding/mandate allows >> us to move toward a more comprehensive solution at the catalog level. >> $0.02 > > Yep yep, I fully agree, especially since it seems we might get one for the > 2.2.0 series. > > So I looked around a bit and it might be that we have it working with > coarse locks > based solely on pluggable callbacks: > * Rest wise I guess I can just plugin a rest callback that checks the current > request method and impose a lock consequently, put/post/delete would raise > a global write lock, all other methods a read one. > * OGC wise I could have a dispatche callback that looks for the WPS > ImportProcess, which is the only thing I know of modifying the configuration. > Maybe have that be configurable somehow, with a list of processes that need > write locking > * GUI wise we need a new extension point, some sort of WicketCallback. > > I noticed that I can change a small bit of GeoServerAppliaction code, > in particular > the RequestCycle class, to spot an admin page: > > static class RequestCycle extends WebRequestCycle { > ... > > @Override > protected void onRequestTargetSet(IRequestTarget target) { > super.onRequestTargetSet(target); > if(target instanceof IPageRequestTarget) { > IPageRequestTarget pt = (IPageRequestTarget) target; > Page page = pt.getPage(); > if(page instanceof GeoServerSecuredPage) { > System.out.println("Hey, this is a secured page"); > } > } else if(target instanceof IBookmarkablePageRequestTarget) { > IBookmarkablePageRequestTarget bt = > (IBookmarkablePageRequestTarget) target; > > if(GeoServerSecuredPage.class.isAssignableFrom(bt.getPageClass())) { > System.out.println("Hey, this is a secured page"); > } > > } > } > > ... > } > > If we want this to be pluggable we could use the onXYZ methods in the > wicket request cycle to build a sort of WicketCallback, that the > RequestCallback would call to. > > This would make the locking code easy to remove by commenting out from > Spring. And/or we could make it possible to turn off in a deplyment by > using a system variable. > > If in the future all config backends support transaction we'd just wipe it > out. > > Would this be acceptable, even for the stable series? > > Also, would this have to be part of its own extension plugin, be part of core > and spread out in the relevant modules, be part of core but be its own > plugin module that only web-app would depend to? > > Cheers > Andrea > > -- > ------------------------------------------------------- > Ing. Andrea Aime > GeoSolutions S.A.S. > Tech lead > > Via Poggio alle Viti 1187 > 55054 Massarosa (LU) > Italy > > phone: +39 0584 962313 > fax: +39 0584 962313 > > http://www.geo-solutions.it > http://geo-solutions.blogspot.com/ > http://www.youtube.com/user/GeoSolutionsIT > http://www.linkedin.com/in/andreaaime > http://twitter.com/geowolf > > ------------------------------------------------------- > -- Gabriel Roldan OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
