Re: Issue - configuring the binary distribution

[Joe Bohn]

Aaron Mulder wrote: On Mon, 1 Aug 2005, Bruce Snyder wrote: At any rate, what I still don't understand is the desire to use a GUI for everything. Any type of UI can be developed if there's an API behind it. Sure, one of the reasons I'm keen on a nice management API. I agree But what I don't agree with is the need to load the server into an unstarted state of some kind just to reconfigure it. Aaron stated previously that he has code to load the configs, change them and write them out again, correct? If I'm missing something, please explain this further. The GBean state is stored in a config store. Without loading part of the server, you don't know where that config store is (file, database, which file, which database, etc.). I mean, we currently only have one implementation (file) storing data in one place (GERONIMO_HOME/config-store) at the moment, but there's no guarantee that will always be true, and I think Jeremy strongly objected to hardcoding stuff to assume any single (config store implementation plus path). Why is this so much different than most applications on the market today?  The standard mechanism to modify configurations that I see is this: - modify properties/xml files when the server is inactive - when the server is active use a command line or GUI to make necessary modifications (presumably using some common management API in the background). - Depending upon the nature of the configuration changes and user requirements the changes may either be temporary for this execution of the server or permanently written to the configuration store. - Configuration changes that make fundamental changes to the server are typically only possible via modification or files that are processed by the server at the next restart.  The server may be active or inactive when changing the files, but they are not effective until the next server restart.   I think this is the behavior/paradigm that most users are familiar with and expect. Anyway, once you have the config store loaded, you can access the saved data for each Configuration. It sounds like one of the configuration items is the specification of the config store itself.  How would a users change the configure store from file to database or from one database to another?  I think for this case you would have to something different (possibly more along the lines of a file/restart mechanism anyway). That essentially contains the state information for a bunch of GBeans for each Configuration. You have two options to actually read and update the GBean state. One is to manually deal with a whole bunch of Serialized junk, depending on specific implementations of certain internals to translate that to usable data and back. The other is to just go ahead and start a kernel and its config store and then load the GBeans from the config store, read and update their properties, and then store them back to the config store again. That handles all the nitty gritty automatically and can't be foiled by changing implementations of various core services. But there are some subtleties here that could use more attention -- I think Jeremy and/or David J dealt with all this when working on the deployer stuff. Right now I believe the server.jar contains the config store information, and the deployer.jar has to contain the same config store information, or else they won't work properly together. There was some talk about separating dependencies and things out of server.jar (to avoid manifest class path entries for reasons that I can't recall), which might make the initial server plan more accessible to deployer.jar and also to whatever the management tool would use. But for the moment, I think they all would need to be built with the same expectations to work correctly together. Grr, really wish we could have this talk around a whiteboard! :) Aaron -- Joe Bohn [EMAIL PROTECTED] "He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot