After Justin's response and a quick discussion in the IRC channel, I think for
now I will do without the ApplicationState class. I believe it will be all
right because RESTConfig will be internally running through the
Submit->Apply->Save cycle we all know and love, so after any RESTConfig
transaction the in-memory configuration will match what's written to disk.
So, the only case I see where the ApplicationState will be inconsistent with
the actual state of the application is this:
Some options are changed using the current UI, then applied, but not saved.
Next, a RESTConfig transaction is done. Now the changes made in the UI have
also been written to disk along with whatever changes are made in the REST
API, but ApplicationState still thinks whatever was done in the web interface
is dirty.
If there are no dirty configuration sections before a RESTConfig transaction
is done, then this will still be the case afterward.
For now, this seems like acceptable behavior. If it becomes problematic later
then I think we can refactor ApplicationSupport in the way Justin suggested.
-David
On Thursday 24 January 2008 12:25:42 Justin Deoliveira wrote:
Hi David,
Seems like you are running up against some of the lovely imitations of
the config :). There are definitely some nasty dependencies in there. If
i had a preference it would be to move the ApplicationState to main and
remove the dependency of validation on it. It would be nice if the
validation stuff was truly pluggable in that web did not have to depend
on it for the system to work. I cant quite remember how much work that
is... but if you want to explore that option i would definitely support it.
But you are correct that its only use is for the UI to track when
something has changed. So if don't need it i suggest you don't use it.
Although I suspect there may be some other trickery that goes on. For
instance if your REST stuff modifies something the UI might need a
kickstart... i am not quite sure.
dwinslow@anonymised.com wrote:
> Hi all,
>
> I'm back to working on the RESTful configuration API
> (http://docs.codehaus.org/display/GEOSDOC/RESTful+Configuration+API)
> after a bit of a break, and I'm having some trouble with dependencies.
>
> The issue is that I need to access the ApplicationState class which lives
> in the web module from my RESTConfig community module (or at least I
> think I do based on the current configuration code); however I've so far
> been simply adding a dependency on RESTConfig to web in order to include
> it in the final war. It seems like it would be nice to move
> ApplicationState to the main module with the rest of the internal
> configuration classes, but this doesn't work out since ApplicationState
> also uses some code from the validation module (which depends on main,
> again introducing a cyclical dependency). Right now I have a build
> working with GeoValidator (from validation) and ApplicationState migrated
> to main, and a bit of somewhat ugly spring hackery in the validation
> module to keep things working.
>
> I could also just get my hands dirty and cut the validation stuff out of
> ApplicationState, possibly rewriting it to load validators at runtime.
>
> A third option is to just not use the ApplicationState class at all. I
> get the impression from looking at the code that it simply keeps track of
> what sections of the configuration are dirty in the web interface, which
> isn't a concern for the REST API since all changes will be flushed to
> disk immediately.
>
> What seems like the way to go forward on this?
>
> /me crosses his fingers in hopes there's a nice clean option #4
>
> Thanks,
> David Winslow
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel