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? > > 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. > > -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 > > !DSPAM:4007,486193de95793327367457! > -- Justin Deoliveira The Open Planning Project [EMAIL PROTECTED] ------------------------------------------------------------------------- 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
