On Jul 26, 2005, at 3:36 PM, Dain Sundstrom wrote:
How is enabling and subsequently configuring a service is
substantially different then just adding a new one? Simmilary, why is
disabling a service substantially different then removing it?
My idea is that live changes should only affect attribute values, not
reference patterns. So, a disabled gbean will still be (potentially)
hooked up to the correct other gbeans, and will have some sort of
attribute values that might possibly be useful. An entirely new gbean
won't have these features.
david jencks
-dain
On Jul 26, 2005, at 3:23 PM, David Jencks wrote:
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
