Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 86710 invoked from network); 20 Jun 2005 11:45:21 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 20 Jun 2005 11:45:21 -0000 Received: (qmail 23523 invoked by uid 500); 20 Jun 2005 11:45:18 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 23484 invoked by uid 500); 20 Jun 2005 11:45:17 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 23467 invoked by uid 99); 20 Jun 2005 11:45:17 -0000 X-ASF-Spam-Status: No, hits=0.5 required=10.0 tests=FORGED_RCVD_HELO,HTML_10_20,HTML_MESSAGE,NO_REAL_NAME X-Spam-Check-By: apache.org Received-SPF: neutral (hermes.apache.org: local policy) Received: from mail.tsainc.com (HELO lng002.tsacorp.com) (206.201.23.30) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 20 Jun 2005 04:45:16 -0700 To: dev@geronimo.apache.org Subject: Usability/Tooling - geronimo configuration on a headless server MIME-Version: 1.0 Sensitivity: X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: sissonj@insession.com Message-ID: Date: Mon, 20 Jun 2005 22:44:19 +1100 X-MIMETrack: Serialize by Router on lng002/SVR/TSA(Release 6.5.2|June 01, 2004) at 06/20/2005 06:44:25, Serialize complete at 06/20/2005 06:44:25 Content-Type: multipart/alternative; boundary="=_alternative 00407B59CA257026_=" X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N This is a multipart message in MIME format. --=_alternative 00407B59CA257026_= Content-Type: text/plain; charset="US-ASCII" 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. --=_alternative 00407B59CA257026_= Content-Type: text/html; charset="US-ASCII"
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. --=_alternative 00407B59CA257026_=--