james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <l...@toolazydogs.com>
Subject Re: [LONG] Re: [jira] Commented: (JAMES-495) Decide how to replace Avalon Configuration
Date Fri, 30 Jun 2006 16:10:42 GMT
Stefano Bagnara wrote:
> This is a big message and I don't have too much time, but it deserve 
> some questions/answers
>
> Bernd Fondermann wrote:
>> I'd like to share some thoughts on a future configuration 
>> architecture within James.
>>
>> = Roles involved in configuration process =
>> [...
>> = Some observations =
>>
>> - Tight coupling between Configuration and Configurable -
>>
>> In James, Configurables themselves read and even parse values from 
>> the ConfigContainer once on startup (method configure()) and often 
>> there are no setter methods (probably to make the components public 
>> interface more lean). That makes it difficult to change those values 
>> dynamically at runtime, e.g. through JMX.
>>
>> The mandatory use of DefaultConfiguration here also makes the unit 
>> test code much more verbose than neccessary
> >
>> = Propositions =
>>
>> - Setters -
>>
>> Let's add setters for all kinds of configuration parameters to the 
>> Configurables in James. If a parameter cannot be set after a 
>> component has become ready or live, the setter throws an 
>> AlreadyConfiguredRuntimeException.
>> This would signal that the component is unable to cope with the 
>> change and that the component would have to be restarted for the 
>> change to become effective.
>> Let's not have the Configurables parse textual configuration 
>> parameters into IPs, integers etc.
>>
>> This could be started soon.
>>
>> (BTW, this topic is not exactly JAMES-494, which deals with dependent 
>> service injection. Here, I am talking about the internal fields a 
>> Configurable populates by reading the configuration.)
>
> I would not like to use setters for components that have a lot of 
> configurations. This would bloat the whole code.

Can you explain your assertion?  The reason for me asking this is 
probably because I'm not totally up to speed w/ the architecture.


Regards,
Alan



---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message