geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <joe.b...@earthlink.net>
Subject Re: Issue - configuring the binary distribution
Date Tue, 02 Aug 2005 12:07:40 GMT
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
Aaron Mulder wrote:
<blockquote
 cite="midPine.LNX.4.58.0508011957561.1908@saturn.opentools.org"
 type="cite">
  <pre wrap="">On Mon, 1 Aug 2005, Bruce Snyder wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">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.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
	Sure, one of the reasons I'm keen on a nice management API.
  </pre>
</blockquote>
I agree<br>
<blockquote
 cite="midPine.LNX.4.58.0508011957561.1908@saturn.opentools.org"
 type="cite">
  <pre wrap="">
  </pre>
  <blockquote type="cite">
    <pre wrap="">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.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
	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).
  </pre>
</blockquote>
Why is this so much different than most applications on the market
today?&nbsp; <br>
The standard mechanism to modify configurations that I see is this:<br>
- modify properties/xml files when the server is inactive<br>
- when the server is active use a command line or GUI to make necessary
modifications (presumably using some common management API in the
background).<br>
- 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.<br>
- 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.&nbsp; The server may be active or inactive
when changing the files, but they are not effective until the next
server restart.&nbsp; <br>
&nbsp;I think this is the behavior/paradigm that most users are familiar
with and expect.<br>
<blockquote
 cite="midPine.LNX.4.58.0508011957561.1908@saturn.opentools.org"
 type="cite">
  <pre wrap="">
	Anyway, once you have the config store loaded, you can access the
saved data for each Configuration.  </pre>
</blockquote>
It sounds like one of the configuration items is the specification of
the config store itself.&nbsp; How would a users change the configure store
from file to database or from one database to another?&nbsp; I think for
this case you would have to something different (possibly more along
the lines of a file/restart mechanism anyway).<br>
<blockquote
 cite="midPine.LNX.4.58.0508011957561.1908@saturn.opentools.org"
 type="cite">
  <pre wrap="">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.  </pre>
</blockquote>
<blockquote
 cite="midPine.LNX.4.58.0508011957561.1908@saturn.opentools.org"
 type="cite">
  <pre wrap="">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


  </pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">-- 
Joe Bohn     

<a class="moz-txt-link-abbreviated" href="mailto:joe.bohn@earthlink.net">joe.bohn@earthlink.net</a>

"He is no fool who gives what he cannot keep, to gain what he cannot lose."   -- Jim Elliot
</pre>
</body>
</html>

Mime
View raw message