Justin Deoliveira wrote: > David Winslow wrote: >> Hi Justin, >> >> I've been looking into using XStream for RESTConfig and possibly >> working on a Catalog backend based on it as well. I've got a few >> questions from my catalog safari, hopefully you can help out. > I have a half implementation that persists and loads the catalog and > config objects which i have not committed yet. I will try to commit > soon as i finish the wfs 1.1 separation work. >> >> 1. It doesn't look like the POJO + Proxy implementation that's >> currently in trunk actually persists the catalog. In particular, I >> see the old SaveXMLAction class is still using the old XMLWriter. > Correct, currently on 1.7.x the only way to save the catalog is from > the UI. My idea for the new UI was to add to > GeoServerLoader.destroy() a routine that persists the catalog via > xstream. > > It also >> appears that Catalog.save() isn't being called anywhere, which seems >> to me to indicate that the catalog should not be changed ever. I >> guess what I am asking here is what we should expect when doing dumb >> stuff like: >> > Correct, the old system works by replacing all application (global) > objects with there ui (config) counterparts. So the way it works today > is that the catalog is entirely thrown away and reloaded every time a > chance is applied. >> Catalog c = ... >> ResourceInfo a = c.getResource(someID); >> alterSomeWay(a); >> ResourceInfo b = c.getResource(someID); >> // does b now reflect the changes made to a? >> // I suspect it should not, since save() has not been called, >> // but the current wrappers seem to rely on this behavior >> // so I am a bit confused. >> > You are correct, that is the intended use. Again, saving directly when > an object is changed (in the current system) is not something that is > supported so its not used. Ideally in the new ui every form that > changes will jsut call save() directly, instead of reloading the > entire catalog. > >> >> 2. There are a couple of failing tests in trunk/main (which are >> masking a lot of failing tests in other modules, oops). It's not >> clear to me whether or not these tests are correct. >> >> CatalogImplTest.testModifyWorkspace(): This seems to be testing that >> changing the name of a workspace does not change its ID; but I don't >> see this expectation documented anywhere. It seems like a reasonable >> one, so maybe we should just add a note about it to the Catalog >> interface. >> >> GeoServerImplTest.testGlobalEvents(): This one seems less mysterious; >> from what I can see it changes 2 properties and then asserts that 3 >> have been changed. This is mostly an implementation detail of the >> current catalog implementation and not that important to my XStream >> work, but I thought I might as well check with you before changing >> tests for the current implementation. > Yeah, fixes for this are coming. I was about to commit them the last > night of the sprint when svn gave out. I just have to sort the commits > out from a bunch of other local mods in my checkout, the fix will come > shortly. >> >> 3. It is not clear to me how much of the current catalog >> implementation is intended to be reusable, though if I had to guess I >> would say that possibly the event implementations are reusable due to >> their simplicity, but not much else. If you have anything to add >> here I'd be glad to find large chunks of reusable code (not holding >> my breath though ;) ) > Not sure exactly what you mean here by reusable. Do you mean by other > subsystems like REST? Or do you mean reusable parts usable by other > catalog implementations? I was thinking of reusing as much as possible for the XStream backend. If the current backend is going to use XStream for persistence anyway then that doesn't mean much :) But yes, I had 'reusable for alternative implementations' in mind there, as opposed to 'reusable by other subsystems,' which I was taking for granted as a design goal. (I also wonder whether (some subset of) the Catalog API could be used for a Java client API for RESTConfig. If done right, this could allow a network of GeoServers to share configuration transparently (configure one to save to a real persistance mechanism, and the rest just sync with it via REST) and be Quite Nifty.) >> >> 4. It seems like the new Catalog API is both Important and >> Complicated. I wonder therefore whether we should start working on a >> test suite for Catalog implementations codifying all the weird >> expectations we have for it. A decent start would probably be to go >> over the current *ImplTest's and try to split off the ones that are >> testing implementation details from the ones that are testing the >> intended behavior; we could add tests as intended behavior proves >> ambiguous. > I don't see it all that likely that another implementation will be > coming along all that soon due to how non-trivial it would be. During > the prototyping of this new api we tested two implementations. The > first was the "in memory" implementation currently on trunk. The > second was a catalog backed onto hibernate. So the interface and > paradigm did hold up against two radically different implementations. > > But I definitely agree that having tests against the interface itself > and against the implementation should be separated. And if we do get > another implementation i suspect it will be mandatory. > Thanks for the quick response. >> >> -David >> >> ------------------------------------------------------------------------- >> >> Check out the new SourceForge.net Marketplace. >> It's the best place to buy or sell services for >> just about anything Open Source. >> http://sourceforge.net/services/buy/index.php >> _______________________________________________ >> Geoserver-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/geoserver-devel >> >> >> > >
------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
