geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <>
Subject Re: Usability/Tooling - geronimo configuration on a headless server
Date Fri, 24 Jun 2005 02:42:03 GMT
On Thu, 23 Jun 2005, Bruce Snyder wrote:
> While I respect your quest for simplicity, I disagree with this
> approach because I think it's too minimal. I think Geronimo needs to
> offer an easy to use, friendly installer/post configurator to the
> community. Installation of commercial app servers is usually handled
> through a GUI installer but configuration has traditionally meant hand
> editing config files. This is not something that I think we can do
> much better.

	We have an installer; I think it's reasonably easy to use.  I'm 
sure it could be improved, but in all honesty, the biggest improvement 
would be to make it run faster.  Right now it deploys the customized plans 
one by one -- it could use the start - multi deploy - stop routine of the 
assembly module, or we could just replace the whole mechanism with 
something to edit the configuration in place.

	(Actually, the biggest improvement would be to have whoever makes 
the unstable builds actually run the installer -- once you have IzPack 
installed you only need to run 1 command to do it!)

> This is exactly why I'm suggesting that we create a library to handle
> the installation and  configuration tasks. It will allow any kind of
> UI to be developed - GUI, text or web - as well as allow for
> scriptable installations. This is extremely powerful and cannot be
> undervalued.

	Sure.  I mean, we could create an API that would edit the config 
info in place.  Presumably now, it would deserialize the stored 
configuration, update it, and then reserialize it back to the config 
store.  I have sample code that does this, and while we'd want some minor 
changes to the config store interface to support it, it's not at all out 
of the question.  However, it would be 10x easier if we just switch to the 
Spring-based configuration system.  :)

	In any case, if we define the API, we can change the background 
however we need to going forward.  It could also support David J's 
suggestion of some kind of "configuration service" that would store the 
ports and similar info separate from the related GBean configuration.  The 
main question to me is, do we create a static set of configuration 
information based on the services available in our "standard" J2EE 
configuration, or do we try to make it dynamic where each configuration 
lists its own configurable properties (using JSR-88, what else? :)  The 
per-configuration system is much more flexible for general-purpose 
configuraitons of Geronimo, but will make our job a lot harder for things 
like sensibly choosing between Tomcat and Jetty (which would just be two 
generic services in that model).

	I'm wandering here, but this isn't the first time I've thought of 
something that would be quite nice for the "J2EE Server Configuration" but 
not terribly useful outside it.  I wonder if we should start a separate 
subproject/directory tree for J2EE-only stuff that does not need to be 
compatible with any general Geronimo configuration.  Perhaps this will 
just be an expanded assembly module.  I'm sure we'll struggle with this to 
some degree with the management console.


View raw message