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
