geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <ammul...@alumni.princeton.edu>
Subject Re: GBeans: Saving Changes
Date Tue, 26 Jul 2005 21:34:59 GMT
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

Mime
View raw message