> 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
-------------------------------------------------------
------------------------------------------------------------------------------
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
