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.
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. 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: 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. 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. 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 ;) ) 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. -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
