geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: GBeans: Saving Changes
Date Tue, 26 Jul 2005 22:36:44 GMT
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?


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

View raw message