On Wed, Nov 9, 2011 at 9:29 AM, 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?
>
Works for me.
>
> 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?
>
I would prefer an extension, since those are trivial to disable... but if
its turns out to be too much work to do it that way then core is fine, as
long as its relatively simple to disable by commenting out a few lines of
spring, etc...
>
> 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
>
> -------------------------------------------------------
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
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
