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
