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 Mon, 20 Jun 2005 16:23:07 GMT
	Well, for configuration purposes, I was thinking something like:

1) Edit XML/text files enough to get ports/security working
2) Start Geronimo, use management web app to get other things working

	I personally prefer that scenario to Swing/Text configuration 
tools.  However, it's a separate issue from upgrade procedures.

	I guess I probably should have clarified that in my original 
response.  I'm not that keen on Swing management tools, though our 
installer package is GUI-only AFAIK.  But I was trying to get to our 
actual requirements, and it sounds like "no GUI options whatsoever" is a 
desired target platform.


On Mon, 20 Jun 2005, Bruce Snyder wrote:

> On 6/20/05, Aaron Mulder <> wrote:
> >         When you talk about a headless server...  Is it acceptable to have
> > a GUI tool that you run remotely via X-over-ssh, or does the server have
> > no X install such that even that wouldn't work?
> Actually, there are situations where this won't be possible. In these
> situations, a strictly command line tool might be more feasible. The
> way I see it, we have three options:
> A) Develop the installer/configurator as a command line tool and
> simply wrap that with a GUI for local installs, or
> B) Develop the main functionality as a library and develop each front
> end separately (e.g. a command line front end using Groovy, a GUI
> using JGoodies, or even a web UI)
> C) Develop two separate tools altogether 
> I would much rather choose option B simply because it would best
> facilitate many front ends and all would utilize the same core
> functionality on the back end.
> >         In any case, I think your writeup is sensible.  However, it may be
> > difficult to implement the upgrade compatiblity where a new install
> > detects and defaults to the settings in an old install.  I'd call this a
> > "nice to have", but in any case it doesn't have to be ready until our
> > second release (so you have something to upgrade from)...  :)
> I agree. Let's get the base install functionality working first. Only
> after that is working should we begin to consider refactoring to
> facilitate upgrades.
> > On Mon, 20 Jun 2005 wrote:
> > > The following are my thoughts regarding requirements for
> > > running/configuring geronimo on a headless server in a production
> > > environment..
> > >
> > > Whatever solution we come up with for changing the configuration settings
> > > (e.g. port numbers) it needs to be 'usable' in a headless environment.  By
> > > that I mean that it should be 'easy' to change the configuration settings
> > > on a headless machine, e.g. not having to regenerate the configuration
> > > from scratch via a GUI on another machine and transfer the configuration
> > > over manually (e.g. ftp) etc.  The solution could be a command line
> > > interface, or it could be a GUI solution that allows one to run a
> > > configuration server component on a specified port (consider that more
> > > than one instance of geronimo could be running on the server and each
> > > instance could be running at a different version) and connect to it from a
> > > client machine (with minimal steps required by the user).
> This is *exactly* why I think a base library for the
> installer/configurator should be developed first. Then we can develop
> any kind of front end necessary.
> > > We should allow GBean attributes to be changed whilst geronimo isn't
> > > running without requiring the configuration be rebuilt from scratch
> > > because whilst geronimo is in production, people may have tinkered with
> > > Gbean attribute values (e.g. via a JMX console) e.g. to tune it, but those
> > > people may have forgotten to make the same changes to the files (XML
> > > plans) that are used to generate configurations the next time around.  The
> > > only time I think it should be necessary to rebuild a configuration from
> > > scratch is when you are installing a new version of geronimo.  When a
> > > configuration is built for a new release, the user shouldn't have to
> > > re-enter all the settings in the GUI again (this would be prone to user
> > > error), they should be able to import the existing configuration into the
> > > configuration tool, with a validation step identifying screens/fields
> > > where new mandatory fields need to be entered in the configuration.
> My thought process has been that the base installer/configurator
> library should have the ability to write out plans. This would
> certainly address the issues above, but will make our job a bit more
> complex because we'll need a manner in which to slurp up the XML plans
> and the the serialized config into a set of beans that can be diffed
> somehow and the present the differences to the user.
> > > Consider the following scenario..  Geronimo has been running for months in
> > > a production environment, where months ago, GBeans attribute values that
> > > configured the locations of files (e.g. transaction logs and database
> > > files) were changed from the default location to point to a different
> > > disk.  At present, Geronimo has been shut down during a hardware
> > > maintenance window where a newer high speed disk has been installed.  The
> > > operations staff now want to change the configuration of the file
> > > locations in some GBean attributes to point to that new disk (they have
> > > moved the files), without touching any other Gbean attribute values that
> > > may have been previously customised (months ago) to minimise risk.
> This is a good example of why I feel that the this application we're
> discussing should not only be an installer, but should also be a
> post-installation configurator (i.e. for existing installations).
> 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
> Apache Geronimo

View raw message