On Jul 26, 2005, at 3:06 PM, Dain Sundstrom wrote:
BTW this is already has a JIRA entry GERONIMO-400. I added this
almost a year ago.
No wonder I couldn't find it. I thought I added it :-)
Now that how saving configuration works has been explained so even I
can understand it, I don't have any problem in saving configuration
locally. I can even imagine a tool to merge a local state with a
configuration to produce a new configuration (with a different version
number or name). Before we jump into adding gbeans to a running
configuration, can we please think about whether the "disabled gbean"
approach would work just as well, and, if not, if the "application
centered deployment" idea would work better. IIRC the original
motivation behind GERONIMO-400 was to put the admin objects you can add
by the admin portal into the original jms configuration rather than
making a separate configuration per queue/topic. If you have the
opportunity to add the admin objects while you are deploying your app
that will use them, I can't actually see any reason to support
deploying "standalone" admin objects at all, whatever configuration
they go into.
thanks
david jencks
-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
