On Mon, 1 Aug 2005, David Jencks wrote:
> So far I am really against adding gbeans to existing configurations. I
> don't have a problem with the web console generating entirely new
> configurations, although I doubt it is all that useful. My opinions
> can always be argued against :-)
It seems like Jeremy and I came to a mutually satisfactory
conclusion where (and I'm summarizing in haste) altering the configuration
(including adding/removing) would be possible, but it would also be
possible to flag specific configurations as not alterable and give them a
specific version number and all. I think that's the best of both worlds
-- if you want it editable, you use the standard behavior. If you want it
locked down so you can guarantee that a deployment performed on machine X
will work when exported and imported into machine Y, then you freeze the
configurations you're dealing with and build machines X and Y from those.
I will apply a little elbow grease to getting David J on board
this week. :)
Aaron
> >> 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
> >> client).
> >> All that aside, the installer package leaves copies of the
> >> (customized) plans it uses. Perhaps the ZIP/GZ package should do the
> >> same.
> >> Aaron
> >> 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)...to 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
> >>>
> >
>
>
