Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Mime-Version: 1.0 (Apple Message framework v622)
In-Reply-To: <C61D10EC-AEC7-481D-9BA7-DD8CFA38B452@iq80.com>
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>
 <13686850-9683-449E-910A-2EF456D6A4A7@iq80.com>
 <4b448a00452ba220db3c7b9fedd4251f@gluecode.com>
 <C61D10EC-AEC7-481D-9BA7-DD8CFA38B452@iq80.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <0f6ad07bc023ef005bd9064f529a9cda@gluecode.com>
Content-Transfer-Encoding: 7bit
From: David Jencks <djencks@gluecode.com>
Subject: Re: GBeans: Saving Changes
Date: Tue, 26 Jul 2005 16:01:04 -0700
To: dev@geronimo.apache.org


On Jul 26, 2005, at 3:36 PM, Dain Sundstrom wrote:

> How is enabling and subsequently configuring a service is 
> substantially different then just adding a new one?  Simmilary, why is 
> disabling a service substantially different then removing it?

My idea is that live changes should only affect attribute values, not 
reference patterns.  So, a disabled gbean will still be (potentially) 
hooked up to the correct other gbeans, and will have some sort of 
attribute values that might possibly be useful.  An entirely new gbean 
won't have these features.

david jencks

>
> -dain
>
> On Jul 26, 2005, at 3:23 PM, David Jencks wrote:
>
>>
>> On Jul 26, 2005, at 3:06 PM, Dain Sundstrom wrote:
>>
>>
>>> BTW this is already has a JIRA entry GERONIMO-400.  I added this 
>>> almost a year ago.
>>>
>>
>> No wonder I couldn't find it. I thought I added it :-)
>>
>> Now that how saving configuration works has been explained so even I 
>> can understand it, I don't have any problem in saving configuration 
>> locally.  I can even imagine a tool to merge a local state with a 
>> configuration to produce a new configuration (with a different 
>> version number or name).  Before we jump into adding gbeans to a 
>> running configuration, can we please think about whether the 
>> "disabled gbean" approach would work just as well, and, if not, if 
>> the "application centered deployment" idea would work better.  IIRC 
>> the original motivation behind GERONIMO-400 was to put the admin 
>> objects you can add by the admin portal into the original jms 
>> configuration rather than making a separate configuration per 
>> queue/topic.  If you have the opportunity to add the admin objects  
>> while you are deploying your app that will use them, I can't actually 
>> see any reason to support deploying "standalone" admin objects at 
>> all, whatever configuration they go into.
>>
>> thanks
>> david jencks
>>
>>
>>>
>>> -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
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>