* 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:
http://wiki.apache.org/geronimo/Architecture/ConfigurationManagement
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 'assemble-on-site'.
-- Jeremy
