[ http://issues.apache.org/jira/browse/GUMP-125?page=comments#action_64198 
]
     
Leo Simons commented on GUMP-125:
---------------------------------

Mailing list thread at

http://mail-archives.apache.org/mod_mbox/gump-general/200504.mbox/[EMAIL 
PROTECTED]

There was more discussion about this further back in the archives as well.

> Flexible way to configure gump in modern unix-like fashion
> ----------------------------------------------------------
>
>          Key: GUMP-125
>          URL: http://issues.apache.org/jira/browse/GUMP-125
>      Project: Gump
>         Type: New Feature
>   Components: Python-based Gump
>     Versions: Gump3-alpha-6
>     Reporter: Leo Simons
>      Fix For: Gump3-alpha-6

>
> Gump2 is configured in the <workspace/> just like Java-Gump was. Gump3 is 
> currently configured through environment variables and the command line 
> (sourcing a shell script for custom settings).
> We should provide a logical and modern way to configure gump through
>   /etc/gump3
> and
>   $HOME/.gump3
> directories where you can safely store configuration data related to the 
> machine or the environment (ie, database to use, JAVA_HOME to use, ...).
> A nice example of an application with flexible configuration support is exim, 
> another one is spamassassin, yet another one is apache2 as provided for 
> debian. Things I would like to see:
>  * conf.d directories to allow spliting config
>  * per-profile config as well as per-machine config
>  * use python's features as much as possible for config features and 
> intelligence
>  * installation of default config files with lots of comments so no RTFM is 
> needed
> One advantage of the gump3 "gump" script is that it has no particular trouble 
> firing up jetty (for dynagump) or apache (for webgump). We really need to 
> keep that flexibility, meaning it might make sense to have the configuration 
> parsing set up almost totally seperately from the rest of gump. We could even 
> consider something that reads the environment and the config files and then 
> generates a really-long-commandline or temporary-shell-script. It could be a 
> reusable python tool :-)
> Or maybe that's a bad idea. We'll see.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to