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:49:18 GMT
On 6/24/05, Bruce Snyder <bruce.snyder@gmail.com> wrote:
> 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.

Actually, I just stumbled upon JSR 38 (Application Installation API
Specification) and http://www.openinstallation.org/ which provides an
implementation of this API named JIFI. This is an extensible API for
creating cross platform installers for many environments, including
non-GUI situations.

> >         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/
> 


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