geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <>
Subject Config management and installation
Date Sun, 15 May 2005 20:48:54 GMT
A couple of questions keep coming up about Geronimo's configuration 
management system; things like:

* How do I change things during installation?
* How do I change things when the server is not running?
* Are we going to give the configuration plans to users?
* WTF is all this stuff anyway?

I was going to include background here but thought it was easier to 
place it directly on the wiki. It can be found at:

With that in mind, here we go ...

During installation we are really doing three things:
1) Installing the kernel and configuration management system
2) Installing the configuration bundles we want this server to run
3) Performing local-server configuration overrides

The first is easy, just install the jars and any of their dependencies 
in the appropriate place. The user will need to specify where that is, 
and will need to specify the configuration management system being used 
(e.g. what are the default Repository, ConfigurationManager and 
ConfigStore implementations).

This gives us a minimal environment where we can install other 
configuration bundles and which can run *inside the installer.* On to 
phase two.

--- Phase Two

Which configuration bundles to install will depend on just what the user 
wants this server to do: is it full J2EE or just the web teir? do they 
want the deployment system configured? is this just an app client 
environment? Based on the responses, the installer can build a list of 
configuration bundles to install, and then use the environment built in 
phase one to to install them.

This leaves us with a server environment built to the user's 
specification with standard bundles installed. That may be enough, but 
if there are local overrides needed, on to phase three.

--- Phase Three

Once the bundles have been installed, the user may still have local 
overrides. For example, we may have installed a generic HTTP connector 
listening on port 8080 and they may want to change that.

The installer has access to the Configuration instances it installed and 
to the persistent properties of the GBeans they contain. Values 
specified in the installer can be used to override those property values 
simply by setting the GBean attributes. The GBeans do not need to be 
started to do that so there is no risk of conflict with other things 
running on the system.

When the installer shuts down its kernel the GBean state will be 
persisted, ready to be restored the first time the user starts the server.


There is no requirement here to give the actual source plans to users. 
They don't form a very friendly UI :-) and instead we should be using 
steps in the installer for the local configuration. Is there an easy way 
to make that modular (e.g. by including helper code in the bundle itself)?

Having said that, the plans do form the ultimate definition of what the 
bundle will contain and I would include them in the distro as 
documentation and so that users don't have to get them from a source 
bundle. We did that with Gluecode's distro.


OK, I hope that makes some kind of sense. If it sounds vaguely familiar, 
it should do - it is very similay to how the assembly module pulls 
things together. I'd almost be tempted to describe installation as 


View raw message