geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: User Configuration of ports, etc.
Date Thu, 25 Aug 2005 02:10:15 GMT

On Aug 24, 2005, at 7:00 PM, Dain Sundstrom wrote:

> On Aug 24, 2005, at 6:29 PM, David Jencks wrote:
>> On Aug 24, 2005, at 6:10 PM, Dain Sundstrom wrote:
>>>>>>> Could I add things rather than override?
>>>>>>     No.  You can do that in the console, but this file just lets

>>>>>> you
>>>>>> override certain attributes for GBeans that are already in the 
>>>>>> server.
>>>>>> You'll notice in the sample there aren't full GBean definitions,

>>>>>> only what
>>>>>> amounts to attribute=value entries.
>>>>> Would anything stop you from doing that though?
>>>> I would.  The idea here is to allow a few attributes to be 
>>>> customized locally even on a server with immutable configurations.  
>>>> editing your configuration contents should use a different system.  
>>>> Most attributes and all references will not be editable in this 
>>>> config db.
>>> I believe that this strategy is a bad idea.  What is going to happen 
>>> is every time we release the software, someone is going to want to 
>>> tweak a setting that we either forgot to make manageable, or we 
>>> wrongly believed shouldn't be managed.  Why not make all attributes* 
>>> manageable?
>> I think perhaps ones point of view on this argument has something to 
>> do with whether one thinks small versioned binary configurations 
>> should be the basic unit of distributing and building a server.  If 
>> you think that versioned binary configurations basically won't work, 
>> then there is no reason to ever inhibit any editing of any 
>> configurations, ever, since each server has no discernable 
>> relationship to any other server.  If you think versioned binary 
>> configurations are the one true path, then you need some way to make 
>> sure that the allowed modifications to a versioned binary 
>> configuration are rather small and don't affect its' essential 
>> character: otherwise the version stops meaning anything.
>> Personally I would like to give versioned binary configurations a 
>> good chance to see if we can make them work: I don't think we have 
>> tried them yet, and if they can be made to work I think they will be 
>> a really cool feature.  I would prefer to see "arbitrary edits" take 
>> place using something like the console or a special tool, and only on 
>> unversioned mutable configurations.
> Excellent point.  I think that shipping an experimental configuration 
> system as the default is bit risky.  As a long term idea, I think that 
> a binary configuration system would be a good option, but I think in 
> the near term we should focus providing a tried an true text based 
> configuration system as the default.
> Now the big question: Is can we deliver a text based configuration 
> system before 1.0 or should we expand on Aaron's configuration 
> overrider to fill in the gap?

umm, it seems to me that you are twisting reality here a little bit :-) 
  I think using anything other than the existing 
known-to-work-although-sometimes-a-pain immutable binary configuration 
system we have been using for a year+ is way too risky for 1.0.  
Getting the very limited config db idea to work for a limited set of 
easy to change attributes should eliminate much of the unbearable pain 
of e.g. not being able to change the ports without excessive risk, I 
hope.  If not, I'm willing to live with not being able to change ports.

A text based configuration system is not possible IMO with the current 
state of gbeans, where we have lots of complex attributes that really 
need to be serialized.  If we had nested gbeans or their equivalent a 
couple months ago I would be much happier with the idea of text based 
gbeandata serialization in the configurations.

david jencks

> -dain

View raw message