geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <ammul...@alumni.princeton.edu>
Subject Re: GBeans: Saving Changes
Date Tue, 26 Jul 2005 22:05:03 GMT
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
> >
> 
> 

Mime
View raw message