Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Date: Mon, 1 Aug 2005 20:26:24 -0400 (EDT)
From: Aaron Mulder <ammulder@alumni.princeton.edu>
To: dev@geronimo.apache.org, Bruce Snyder <bruce.snyder@gmail.com>
Subject: Re: Issue - configuring the binary distribution
In-Reply-To: <7b3355cb050801163714954f91@mail.gmail.com>
Message-ID: <Pine.LNX.4.58.0508011957561.1908@saturn.opentools.org>
References: <42EE58C1.2030809@savoirtech.com>
  <Pine.LNX.4.58.0508011838380.1908@saturn.opentools.org>
 <7b3355cb050801163714954f91@mail.gmail.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

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.

> 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).

	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.  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