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:06:13 GMT
BTW this is already has a JIRA entry GERONIMO-400.  I added this  
almost a year ago.


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