http://jira.codehaus.org/browse/GEOS-4297 is the JIRA issue. I have attached a patch that, I believe, contains all the changes discussed in this thread.
-- David Winslow OpenGeo - http://opengeo.org/ On Mon, Jan 10, 2011 at 12:31 PM, Justin Deoliveira <jdeol...@opengeo.org>wrote: > > > On Mon, Jan 10, 2011 at 10:22 AM, David Winslow <dwins...@opengeo.org>wrote: > >> 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. >> > > Great. But just be warned that this will be changes to core code. And last > week we pushed back RC1 to accomodate some core security changes. The > concerns raised there will probably be apply here in that it seems risky to > make a bunch of core changes and then stamp it RC1 directly after. However I > imagine the scale of these changes to be smaller so I guess we can discuss > that when we have a patch in hand. > >> >> 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. >> >> Big +1. I think an extension point makes a lot of sense and indeed > something that came up in the past. It also gives smaller extensions that > store metadata on catalog entries a chance for validation. > > >> -- >> 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. >>> >>> >> > > > -- > 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
