Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Mime-Version: 1.0 (Apple Message framework v733)
In-Reply-To: <Pine.LNX.4.58.0507261748360.23546@saturn.opentools.org>
References: <Pine.LNX.4.58.0507242238240.22951@saturn.opentools.org>
 <42E557AB.2030201@apache.org>
 <Pine.LNX.4.58.0507251939001.15627@saturn.opentools.org>
 <42E59B4E.6070105@apache.org> <0a86052ced8d9c54d70e001c840995d7@gluecode.com>
 <Pine.LNX.4.58.0507261500450.22350@saturn.opentools.org>
 <42E6A162.20400@apache.org>
 <Pine.LNX.4.58.0507261715360.23546@saturn.opentools.org>
 <6a55a4b8c80c32cb2993015b7487eff4@gluecode.com>
 <Pine.LNX.4.58.0507261728330.23546@saturn.opentools.org>
 <7c430098b6c9e4be71e5e5468a9a7e27@yahoo.com>
 <Pine.LNX.4.58.0507261748360.23546@saturn.opentools.org>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <13686850-9683-449E-910A-2EF456D6A4A7@iq80.com>
Content-Transfer-Encoding: 7bit
From: Dain Sundstrom <dain@iq80.com>
Subject: Re: GBeans: Saving Changes
Date: Tue, 26 Jul 2005 15:06:13 -0700
To: dev@geronimo.apache.org

BTW this is already has a JIRA entry GERONIMO-400.  I added this  
almost a year ago.

-dain

On Jul 26, 2005, at 3:05 PM, Aaron Mulder wrote:

> David,
>     I believe we need to be able to make this kind of change to a
> running server.  The commercial products we're (at least in theory)
> competing with all support making this kind of change through their
> management console, though for certain types of changes a server  
> restart
> is required.  Changing the port you're using to connect to the  
> console at
> runtime would be a little weird, but I'm strongly opposed to requiring
> someone to locate, modify, and redeploy the o/a/g/Server plan in  
> order to
> make any change at all.
>
> Jeremy,
>     I agree that changing an attribute value does not need to alter
> "the configuration" based on what is implemented today.  IIUC, when  
> you
> alter a GBean, a new set of config info is written to a separate  
> file, and
> next time the configuration is loaded that file is read and the new  
> value
> kicks in instead of the original value.  So you have both the  
> unaltered
> original configuration and the modified "current state", and it just
> happens that future server starts will use that "current  
> state" (though I
> suppose we could provide some sort of command to revert a  
> configuration to
> its original state).  That would actually be a kind of cool option  
> in the
> console -- "revert to factory default settings".
>
>     Maybe I've been casting this entire discussion in the wrong way.
> Both changes to GBean properties and adds/removes of GBeans can be
> accomplished by adjusting the "current state" saved *in addition  
> to* the
> original state -- so at the end of the day, we're not really  
> altering "the
> configuration", we're preserving the original configuration and  
> altering
> our "current state for the configuration".  Perhaps we're in violent
> agreement.  :)
>
> Aaron
>
> On Tue, 26 Jul 2005, David Jencks wrote:
>
>> 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.
>>
>> thanks
>> 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
>>>
>>>
>>
>>
>