geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <>
Subject Re: Issue - configuring the binary distribution
Date Mon, 01 Aug 2005 22:42:45 GMT
	I want to provide the necessary features in the web console to
handle the stuff that a user is likely to want to change.  I further would
like to have that implemented under the covers by a management API that
can be invoked outside of the web console.  I further have the idea that
to change stuff while the server is "not running" (including parts that
barf on startup) we could load the server into a loaded-but-not-started
mode and then use the management API against that -- presumably with some
kind of command line tool, that's much more limited that the web console
(at least, the minimum requirements are ports and perhaps SSL
configuration, because those are the things that actually prevent you from
starting the server to run the web console or a generic JMX or JSR-77 

	All that aside, the installer package leaves copies of the
(customized) plans it uses.  Perhaps the ZIP/GZ package should do the


On Mon, 1 Aug 2005, Jeff Genender wrote:
> Hi,
> I want to open up a discussion for binary distribution.
> Currently we are not packaging the plans in the binary distribution. 
> This will likely cause some issues with the users as it will be 
> inevitable that the configurations will need changing.  Examples will be 
> SSL certificates (i.e. keyfiles) have an AJP connector or 
> not...have a Realm that covers the entire server, or even Virtual Hosts. 
>    These are all typically server level configurations and much less at 
> an application specific level. I would say most users who want to use 
> Geronimo in production *will* be having a need to change the 
> configuration, and I think rebuilding from source is not acceptable.
> We need to make the ability to alter these objects and easily change the 
> config without the need to download the entire source base.
> I think this is a critical path issue that we need to address before a 
> 1.0 release as it will cause huge complaints IMHO.
> My .02...I think that packaging the plans with the assembly (and maybe a 
> maven script or other to easily enable a redeployment (cli?)) is a short 
> term solution and something we need to come to terms with, but we should 
> also discuss our long term goals around this.
> Comments?
> Jeff

View raw message