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
Sure, one of the reasons I'm keen on a nice management API.
Why is this so much different than most applications on the market
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
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).
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
- 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
I think this is the behavior/paradigm that most users are familiar
with and expect.
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).
Anyway, once you have the config store loaded, you can access the
saved data for each Configuration.
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.
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
"He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot