So I've been thinking and researching this stuff a decent bit recently,
since frankly change scares me :)
The XStream stuff looks pretty great. I like that you can alias objects
for more readable xml names, as that's fairly important to me. I don't
need incredible readable xml files, but I think it's nice if one can
play around with them and figure things out. Another promising sign to
me is that a number of the rest java plugins make use of xstream, I
think both the grails one and the struts 2 one.
I'm also thinking that it may make sense to use hibernate for our
default persistence mechanism. The lazy loading stuff seems really
nice, and hibernate really has become the standard way to persist
objects. One question I have is whether we should consider using the
Java Persistence API, which hibernate supports I believe, or if we
should just use hibernate's api directly.
I agree that if the rest api is easy enough to use then it could
decrease the need for people to mess with the xml files directly. But I
also hope we have a way to maintain the portability of configs. I think
we'd need a rest api endpoint that would take a zip of config files, or
else one big config file. One should be able to interact with smaller
end points, but sometimes you may just want to upload a whole
configuration from another place. But hopefully we can use xstream in a
smart way, to communicate both smaller rest api end points and the whole.
I am curious how things like our SLD files might play in to this though.
And there's also stuff like our templates, which aren't xml. It
makes sense to expose these through a rest api for sure. But I guess it
speaks to the fact that we'd have to do some zip file data dir type
thing if we want to pass around full configs.
Andrea Aime wrote:
> Justin Deoliveira ha scritto:
>> Chris Holmes wrote:
>>> Cool, either approach works fine for me. I see advantages both ways,
>>> but I'm not the one who's going to be working with the code directly, so
>>> I defer to you guys. I think I may have some questions on specifics,
>>> but how about you go ahead and make a GSIP Justin? Can have a couple
>>> sample classes to show it?
>> There is already a full blown GSIP for the work here.
>> There are links to code and a maven module you can build which includes
>> the model itself, as well as an xstream and hibernate persistence layer.
>> I can add a section on our integration strategy. However it would be
>> nice if the rest of the proposal got another review, especially from Andrea.
> I'll sure do.
>>> And I guess you're saying that this will involve a new persistence
>>> mechanism as well? That will be the big change, no?
>> Depends on if we feel like breaking backwards compatability with out
>> current xml configuration file format. If we say ok, lets break it, then
>> yes I would propose to move to a new persistence mechanism (xstream).
>> Which is a lot simpler (like 3 lines of code to persist, 3 lines to read).
> I'm for breaking compatibility and calling it GeoServer 2 if it needs
> to be. The main point of changing config subsystem is to kill a system
> that makes us avoid any config change. It must be easy to add and alter
> the current configuration. Trying to keep backwards compatibility would
> make it hard.
> Oh, one thing. The natural output of XStream is a single big xml file,
> not a set of files like now. When object A has a reference to object B,
> xstream follows it and serializes B too, and so on. This has obvious
> scalability issues (no more, no less than the current system, which
> does write multiple files in a single shot, without any way to
> persist a partial change).
> There is a way to create multiple files in XStream, but I'm not
> sure it's what we want, see http://jira.codehaus.org/browse/XSTR-52
> If we want GeoServer to scale config wise a lazy load/lazy save
> mechanism is required, and that probably needs a database based backend
> (see the Hibernate side of the proposal). But... are we going to mantain
> it if it's not the primary persistence mechanism?
> Oh, one thing. One of the major drawbacks of the current config system
> is that it reloads all datastores and all feature types each time one
> does apply or load. This is quite a problem when having big amounts
> of configured feture types, or slow datastores (think remote wfs).
> The new config system should be careful to only reload datastores and
> feature types whose configuration changed (even driven, I kind of
> remember the new config system is, but I'm not sure).
>> However to be clear the format xstream saves its output in is not really
>> intended to be human readable. Its basically just a dump of java objects
>> in xml.
> There are way to alias the class names so that the xml looks better,
> but yes, one should not think the files as a xml schema based
> information model, but just a way to dump a net of java objects into
> a text file with a format that happens to be xml. Btw, XStream does
> support JSON persistence too in the latest releases. Maybe this could
> make it even more clear that the configuration is not meant to be
> subject to a schema and so on?.
> I believe if the REST api is simple and general enough to use we can
> just discourage people to try and fiddle with our persisted
> configuration files.
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> Geoserver-devel mailing list