geronimo-dev mailing list archives

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

On Aug 24, 2005, at 7:10 PM, David Jencks wrote:

> On Aug 24, 2005, at 7:00 PM, Dain Sundstrom wrote:
>> 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.

I know a lot of this serialized configuration topic gets to changing  
ports, but I want to go on record one more time and say that binary  
configurations will not work for upgrades.  It won't be till we  
remove all details from our configurations that expose the inner-most  
structure of classes that we will have the possibility to upgrade  
without a complete redeploy.

As I've had this perspective for quite some time, I fault myself for  
not breaking from mainline backing my opinion with code.


View raw message