geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Snyder <bruce.sny...@gmail.com>
Subject Re: Usability/Tooling - geronimo configuration on a headless server
Date Fri, 24 Jun 2005 06:22:26 GMT
On 6/23/05, Aaron Mulder <ammulder@alumni.princeton.edu> wrote:
> 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.

IMO, installation and configuration are very similar and each can be
achieved using the same UI, but two different APIs underneath - one
for installation and the other for configuration. This is why I keep
talking about an installer and a configurator together. The installer
API should make use of the configurator API.

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.

>         (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.  

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.

>         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 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'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.

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.

Bruce 
-- 
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'

The Castor Project
http://www.castor.org/

Apache Geronimo
http://geronimo.apache.org/

Mime
View raw message