geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Usability/Tooling - geronimo configuration on a headless server
Date Mon, 20 Jun 2005 22:59:15 GMT
Aaron Mulder <> wrote on 21/06/2005 12:59:54 

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


> Aaron
> 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 
> > (e.g. port numbers) it needs to be 'usable' in a headless environment. 
> > that I mean that it should be 'easy' to change the configuration 
> > on a headless machine, e.g. not having to regenerate the configuration 

> > from scratch via a GUI on another machine and transfer the 
> > 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 
> > Gbean attribute values (e.g. via a JMX console) e.g. to tune it, but 
> > people may have forgotten to make the same changes to the files (XML 
> > plans) that are used to generate configurations the next time around. 
> > only time I think it should be necessary to rebuild a configuration 
> > 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 
> > error), they should be able to import the existing configuration into 
> > 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 
> > 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. 
> > operations staff now want to change the configuration of the file 
> > locations in some GBean attributes to point to that new disk (they 
> > moved the files), without touching any other Gbean attribute values 
> > 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 
> > error has misdirected this e-mail, please notify the sender 
> > and destroy this e-mail.  Any review, dissemination, use or reliance 
> > this information by unintended recipients is prohibited.  Any opinions 

> > expressed in this e-mail are those of the author personally.

View raw message