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 12:36:29 GMT
On Fri, 24 Jun 2005, Bruce Snyder wrote:
> We've already agreed that a GUI-only installer does not meet all
> requirements. But many sys admins also want the ability to automate
> installs via scripting.

	OK, if I remember right, you can go through the installer in GUI 
mode, and then when you finish, save all your selections as a script, and 
run the same install without a GUI later.  Still not a full non-GUI 
installer, but definitely a bridge.

> >         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.  
> I agree that editing configurations in this manner is a good idea
> because it suits performing a reconfiguration of existing installs.
> > However, it would be 10x easier if we just switch to the
> > Spring-based configuration system.  :)
> I agree that switching to a Spring-based configuration would be ideal!
> I'm just not sure we want to require Spring.
> I think we need to prioritize these requirements to determine how to
> design such an API. But this is exactly why I think an API should be
> put together to handle this correctly rather than just hacking
> together a simple config editor. Let's start a JIRA issue for it and
> begin to list the requirements.
> I think what you speak of here are just many different custom
> assemblies and the installation and configuration APIs need to be able
> to handle them. Using Spring would simplify this tremendously, but I'm
> not yet convinced that we want to require Spring. But doing what James
> did for ServiceMix might nudge me a bit more. He wrote a custom Spring
> bean factory to simplify the Spring configuration. The result is a
> cleaner XML file, while still allowing all of Spring's niceties. This
> would really be the best of both worlds.

	But where does code go that only works for one particular
assembly?  Does the assembly begin to contain other code or modules in
addition to the raw "assembly" script?


View raw message