Hi Tara, First off there was never a schema published for the rest configuration api. The author (Ronak) I believe generated one on his own. There was some discussion on the list about whether to generate a schema or not.
But yes your findings sound reasonable and I like the approach (only changing what you care about and preserving the rest). At the same time I also see the case for a stable schema for developers to write against. Tough call. There is actually talk currently going on to factor out some of the geoserver internals into a reusable client module. This would give java clients the same object model that we use internally in geoserver. The real benefit would be that all the XML marshaling/unmarshalling that exists in Geoserver today could be reused by the client. This is still a little far off though. But would probably be the most robust way to build a java restconfig client. I like the DOM approach though as you propose. It is nice and simple. 2 cents. -Justin On 4/12/10 10:10 AM, Tara Athan wrote: > I have been looking at the restconfig-java code... I had hoped there > would be an easy temporary fix for all the missing parts that would just > leave the missing parts unchanged, but the way the code is set up I do > not see any easy way to do that. This is because it uses "@Xml..." > annotations from the javax.xml.bind.annotation package to translate the > xml into java objects, uses mutate methods to change things and then > translates back to xml. So the code needs to be fixed to have all xml > elements properly translated so that it doesn't wipe them out. > > I am wondering if this is a reasonable approach- unless the Rest schema > is very stable, this code will have to be carefully updated anytime > something new is added to the schema, or it will cause these new > elements to be wiped. > > I am guessing this is what happend with the current code- it looks like > the author wrote it to correspond to a different xml schema, and then > the schema changed. Actually now that I know how it is supposed to > work, I am reluctant to fix it, because then it becomes dangerous if the > Rest schema changes, unless there are checks that will verify that the > complete xml element was translated and shut down before any harm is done. > > Before I heard of the restconfig-java module, I was working on some PHP > that would download the xml into an object, change certain things, leave > everything else the same and then upload. I think a similar approach > would work in java using the DOM API. Although this is not as slick as > using the @Xml annotations, it seems more robust to me. > > Comments are appreciated, > Tara > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > 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. ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
