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
