OK, I think I'll go back to my PHP scripts, as the java project has
morphed into something way beyond my experience and time available.
That should solve my immediate needs and perhaps produce something
useful to others as a batch approach to the cURL commands.
Thanks for all your insights, Tara
Justin Deoliveira wrote:
Hmmm... i would say this is a different issue all together. How to
handle changes to the core configuration model (and consequently the
representations of resources in the rest api) seems a bit different than
having a client being able to round trip all information working against
a single version.
I do like the idea of having version information in the header and
encouraging clients to specify versions of the api they know are supported.
On 4/13/10 9:37 AM, David Winslow wrote:
Actually, it seems the shared-model-object approach would be subject to
the same issues described in this thread, if you mismatched versions of
the rest client and the rest service. This would make it tough for
distributers of tools based on the RESTConfig service. I guess an easy
fix would be to add some versioning info (like a
'X-GeoServer-REST-Version: 2.0.1' HTTP header or a '?v=2.0.1' query
parameter) to each request and have the service refuse to handle
transactions that mismatched in version. This would just make the
mismatch less destructive, though.
I think in the end, client implementers will do best by modifying a dom
(or a nested map structure if they are working against JSON) and simply
preserving unrecognized entities.
--
David Winslow
OpenGeo - http://opengeo.org/
On 04/13/2010 11:25 AM, Justin Deoliveira wrote:
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
------------------------------------------------------------------------------
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
--
Tara Athan
Owner, Athan Ecological Reconciliation Services
tara_athan at alt2is.com
707-272-2115 (cell, preferred)
707-485-1198 (office)
249 W. Gobbi St. #A
Ukiah, CA 95482
|
------------------------------------------------------------------------------
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
