geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: GBeans: Saving Changes
Date Tue, 26 Jul 2005 21:40:02 GMT
IMO both of these are much better done as part of the offline 
deployment process well before the configuration gets anywhere near a 
running server.  Both of these are reasonable things to do, but again 
IMO not on a running server.

I'm not really sure how the current configuration saving works.

david jencks
On Jul 26, 2005, at 2:34 PM, Aaron Mulder wrote:

> On Tue, 26 Jul 2005, David Jencks wrote:
>> there are at least 2 aspects to mutable configurations.
>> 1. adding/ removing gbeans.  I don't think there is a valid use case
>> for this and don't think we should support it, ever.  I don't think we
>> should allow changing reference patterns either for essentially the
>> same reasons.
> Use case: Server ships with HTTPS or AJP disabled.  You want to enable 
> it.
> You go to the console, fill in a form, click a button, it is now 
> running.
> Under the covers, a connector GBean has been added to the o/a/g/Server
> Configuration.
>> 2. changing attribute values on pre-existing gbeans.  To me this is
>> less clear.  I'm not thrilled with the idea of changing the content of
>> a configuration jar: I'd prefer to see local modifications saved in a
>> local database outside the supplied configurations.  I can see how you
>> would want to play with a running server till you like it, then save
>> and seal a configuration, but I'm reluctant to allow this without more
>> thought and a clear upgrade path to whatever we decide we want to do
>> long-term.  Still, this seems more reasonable to me than (1).
> Use case: server ships with HTTPS pointing to a self-signed cert.  You
> want to point it to a real cert, which requires the server to use a
> password different than "secret".  You go to the console, fill out a 
> form,
> and the GBean property is changed to use the correct password.
> As for your implementation thoughts, I thought this is essentially what
> was implemented -- that saved state was saved to a different place than
> original state.  I do not think we need the scope creep of creating
> another database just for this.
> Aaron

View raw message