Re: Usability/Tooling - geronimo configuration on a headless server

[sissonj]

Aaron Mulder <[EMAIL PROTECTED]> wrote on 21/06/2005 12:59:54 AM:

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

There are enterprise platforms (in the mainframe class) do not have X installed and their JVMs are headless (e.g. if you attempt to use the AWT classes you will get a HeadlessException).

>
>    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 the upgrade capability is isn't needed until the 2nd release, but it would be nice to have a high level plan on how it could be achieved to ensure the configuration information in the 1st release doesn't end up going up a dead end.

John

>
> Aaron
>
> On Mon, 20 Jun 2005 [EMAIL PROTECTED] 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).
> >
> > 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.
> >
> > 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.
> >
> > Comments?
> >
> > John
> >
> > This e-mail message and any attachments may contain confidential,
> > proprietary or non-public information.  This information is intended
> > solely for the designated recipient(s).  If an addressing or transmission
> > error has misdirected this e-mail, please notify the sender immediately
> > and destroy this e-mail.  Any review, dissemination, use or reliance upon
> > this information by unintended recipients is prohibited.  Any opinions
> > expressed in this e-mail are those of the author personally.