Hi Sam, Thanks for the feedback. I agree it looks like an explicit update to the "config" objects is missing. What type of information is being lost on shapefile upload? Unless I am mistaken not updating the config objects should only affect the UI.
-Justin Sam Brodkin wrote: > Justin, > > all good suggestions. > > We are using the RESTful API intensively now with 1.7.1 and it's working > well with a one exception that we should keep in mind going forward. > > If you look in RESTUtils in the reloadconfiguration() method, you'll > notice that the update config portion is left out. The code (taken from > the loadGeoserver() method of org.vfny.geoserver.action.LoadXMLAction) > was not copied over because the config objects come from the > ServletContext (not available in the RESTlet). I'm hoping the "new" > catalogue API won't have this limitation (of being tightly coupled to > the web app). Anyway as a result we're losing some configuration data > after a shapefile upload. > > In the meantime does anyone know a workaround to get the config (global, > data, wcs, wfs, and wms) reloaded without making an HTTP call to the > admin webapp (that won't be available for us in production. > > > > > > On Sun, Jan 11, 2009 at 2:20 AM, Justin Deoliveira <[email protected] > <mailto:[email protected]>> wrote: > > Hi all, > > I spent this last week looking at the rest config module in preparation > in moving it toward supported. First off I want to say I really like > restlet, and in particular the framework David has set up in GeoServer. > It is quite easy to use and understand. That said I do think there is > room for improvement. Here are some of the higher level things i have > come up with. > > * Old Configuration / Catalog API > > All the code is written against the deprecated configuration api. A > while back when I did an initial review I brought this up and the > response was that this would be something we would look at when moving > rest config to supported, but for the purposes of experimentation we > would just write against the old api. Well that time has come. > > In my opinion the code should work against the new api. I don't think it > makes a lot of sense to release the code when we know it will need a > major overhaul shortly after. Now at first thought this would require a > lot of work, however i have some other suggestions below that will save > a lot of the work. > > * Reflection vs Maps > > Currently "resources" in rest config all extend from a generic class > called MapResource. MapResource works by having subclasses transform an > object (say a FeatureTypeInfo) into a map, and vice versa. > > While this approach is straight forward and simple I think a reflection > based approach would result in a lot less code. Especially for the new > catalog and configuration interfaces. We all ready have a bunch of > reflection utility classes (used by the ows dispatcher and xml parsers). > And Andrea even made them fast by introducing a cache. > > Anyways, I think having a MapResource around is definitely useful for > some cases, but I think another base class called something like > "ReflectiveResource" would also be useful. > > * Serialization and De-serialization via XML and JSON > > An even bigger win with the reflective approach would be the > serialization/de-serialization as XML and JSON via xstream. We already > has code that does this as part of saving the configuration as xml with > xstream. The exact same code can also be used to serialize as json with > one flag set. So that basically means we don't have to write any custom > serialization or de-serialization code. It also has the nice side-effect > that when we output a resource via rest, it matches how we save the > resource to disk. > > * Freemarker Templates for HTML output > > Currently when a resource is serialized as html it uses a built-in > template. I think it makes sense to make this customizable for users > with our fancy template system. I don't think this will be too much > work. Basically just configure the template configuration used by > FreemarkerFormat to use the GeoServerTemplateLoader to find a template, > and fall back on the built-in templates. > > Thats it for now :). > > -Justin > > -- > Justin Deoliveira > OpenGeo - http://opengeo.org > Enterprise support for open source geospatial. > > > ------------------------------------------------------------------------------ > Check out the new SourceForge.net Marketplace. > It is the best place to buy or sell services for > just about anything Open Source. > http://p.sf.net/sfu/Xq1LFB > _______________________________________________ > Geoserver-devel mailing list > [email protected] > <mailto:[email protected]> > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Check out the new SourceForge.net Marketplace. > It is the best place to buy or sell services for > just about anything Open Source. > http://p.sf.net/sfu/Xq1LFB > > > ------------------------------------------------------------------------ > > _______________________________________________ > Geoserver-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geoserver-devel -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------------ Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
