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?
-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
