Apologies for both the low code quality and the late timing, this code was kind of a back-burner experiment. I would like to get it into RC1 however and can put some more serious effort into it this week.
I gather the design should be something along the lines of: - CatalogImpl::validate becomes public API (moving to Catalog::validate) - The validation code I added in ResourceInfoImpl moves to CatalogImpl::validate(ResourceInfo, boolean) One question comes to mind: would it be worthwhile to make this an extension point (for example, the style requirement would only be enforced if you have WMS disabled)? I guess the WMS/WFS/WCS related fields are pretty well baked-in to the catalog so perhaps it wouldn't be useful. -- David Winslow OpenGeo - http://opengeo.org/ On Mon, Jan 10, 2011 at 11:48 AM, Justin Deoliveira <jdeol...@opengeo.org>wrote: > > On Sat, Jan 8, 2011 at 7:20 AM, David Winslow <dwins...@opengeo.org>wrote: > >> Upload to existing datastores sounds pretty useful to me... I notice the >> example only mentions the .../file.shp endpoint; will url.shp and >> external.shp also be supported? >> > > Yup, url and external are supported as well. > >> >> I have also been working on some improvements to RESTConfig - with respect >> to error handling. The motivation is that in GeoNode we don't do a lot of >> validation on shapefiles before passing them along to GeoServer, figuring >> that our validation won't necessarily match GeoServer's anyway. If the >> import fails somehow (most often due to a missing/unrecognized PRJ file) >> then the layer is enabled anyway, and GeoServer's WMS capabilities document >> fails after that. (We currently have some fairly kludgy code that runs >> after such uploads to try and clean up.) >> >> I think it would be better if the RESTConfig importer would disable a >> layer if it doesn't have all the required fields for continuing WMS (and >> WFS/WCS/etc) service. I've done some work on it for WMS already (though I >> am sure some refactoring is in order.) Diff is at >> https://github.com/dwins/geoserver/compare/master...dont_break_wms_via_rest(and >> if you want an actual diff file, just add .diff to the end of the URL). >> > > I agree that indeed disabling the layer if it is invalid makes sense. As > for the patch I think it needs some work. For one all the existing > validation lives in the catalog itself, so it would be nice to keep it there > rather than in the catalog info classes which by design we try to keep as > "dumb" as possible. > > Currently CatalogImpl has a set of "validate" methods it uses for internal > validation. There was talk before about making them actually part of the > Catalog interface and make them actual api. This strengthens that case. > > Anyways, while I am all for the changes I think some more work still needs > to be done before this gets in. And as it will probably require core changes > I am tempted to push it off until after RC1. Although if David has time to > put into this I will do my best to help it along. > >> >> -- >> David Winslow >> OpenGeo - http://opengeo.org/ >> >> On Sat, Jan 8, 2011 at 2:49 AM, Andrea Aime <andrea.a...@geo-solutions.it >> > wrote: >> >>> On Fri, Jan 7, 2011 at 7:01 PM, Justin Deoliveira <jdeol...@opengeo.org> >>> wrote: >>> > Hi all, >>> > With the pushing back of RC1 by a week I could not help myself to whip >>> up >>> > two pending proposals having to do with restconfig. >>> > >>> http://geoserver.org/display/GEOS/GSIP+59+-+Promote+RESTConfig+to+Core+Module >>> > >>> http://geoserver.org/display/GEOS/GSIP+58+-+RESTConfig+API+Improvements >>> > >>> > The first I don't imagine will require too much discussion and actually >>> has >>> > already been more or less agreed upon by devs. It is the promoting of >>> > RESTConfig to core module. It is pretty low risk so I don't forsee much >>> > resistance to getting it into RC1. >>> >>> Little resistance? Ha, power up your lightsaber and face me then! >>> (kidding, of course +1 to get restconfig into core) >>> >>> > GSIP 58 though probably requires more discussion. Although it was >>> discussed >>> > in this previous email thread: >>> > http://old.nabble.com/some-restconfig-improvements-td30202559.html >>> > The outcome of that proposal was two fold: >>> > 1. It would be good to somehow share code or merge this with the wps >>> import >>> > functionality. >>> > 2. Some concerns about this functionality continuing down the rest good >>> > practice violation path >>> > Both good concerns. For (1) I would like to push off as a future >>> > improvement. I have some ideas about how to factor out such code but it >>> > would be a significant under taking. >>> > For (2) I think it was agreed that fixing these mal practices will have >>> to >>> > be something done in a version 2 of the api in which we can break some >>> of >>> > the api. >>> > As for getting GSIP 58 into RC1 or even 2.1.0 I am not going to push on >>> > that, i want to hear peoples opinions on that. On the one hand I want >>> to >>> > push for more modest development which means holding back on features >>> like >>> > this. On the other hand since its a public api addition it would be >>> good to >>> > get it into 2.1.0. >>> >>> Works for me, +1 on this one as well >>> >>> Cheers >>> Andrea >>> >>> -- >>> Ing. Andrea Aime >>> Technical Lead >>> >>> GeoSolutions S.A.S. >>> Via Poggio alle Viti 1187 >>> 55054 Massarosa (LU) >>> Italy >>> >>> phone: +39 0584962313 >>> fax: +39 0584962313 >>> >>> http://www.geo-solutions.it >>> http://geo-solutions.blogspot.com/ >>> http://www.linkedin.com/in/andreaaime >>> http://twitter.com/geowolf >>> >>> ----------------------------------------------------- >>> >>> >>> ------------------------------------------------------------------------------ >>> Gaining the trust of online customers is vital for the success of any >>> company >>> that requires sensitive data to be transmitted over the Web. Learn how >>> to >>> best implement a security strategy that keeps consumers' information >>> secure >>> and instills the confidence they need to proceed with transactions. >>> http://p.sf.net/sfu/oracle-sfdevnl >>> _______________________________________________ >>> Geoserver-devel mailing list >>> Geoserver-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel >>> >> >> > > > -- > Justin Deoliveira > OpenGeo - http://opengeo.org > Enterprise support for open source geospatial. > >
------------------------------------------------------------------------------ Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
