Re: [LONG] Re: [jira] Commented: (JAMES-495) Decide how to replace Avalon Configuration

[Bernd Fondermann <bf...@brainlounge.de>]

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:
> 
>> = 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.
> Maybe we should use configuration objects (dto) for complex configurations.
> ConfigurationObjects (or single configuration properties) should be 
> immutable, so if you want to reconfigure you have to create a new 
> configuration and use the setter to reconfigure the component.

If objects have too much setters they probably have too much fields. 
Having too much fields makes classes smell and they should become 
refactoring targets. the bloat should not be the setters problem.

The refactoring could be to group field variables into 1..n classes 
depending on which belong together semantically.

This magically reduces the amount of setters.

> 
> When do we validate a configuration?

Syntactically: on mapper level. semantically: on Configurable level.

> Syntax validation and some logical validation could be done in the 
> mapper, but what for business logic configuration constraints?
> 
> Maybe we currently have code in the configure methods that could not be 
> done outside the component (Sorry I don't  have examples now).

Definitively. Very important point.
We'd still in many cases have to initialize a component. I am currently 
trying to get (as far as possible) this code/logic out of 
initialize()/configure() into separate and (for now) private methods. 
These are candidates to be called from outside in the future.

It is the very nice side-effect that those sometimes a bit bloated 
methods look much more fresh.

> 
>> - Restarting components -
>>
>> Restarting (=redeploying) a component as the configuration was altered 
>> is not an easy thing to do, IMHO. (Its easy if components are idle, 
>> don't hold any resources and there are no dependencies between 
>> components. That's not the canonical case.) It probably in the end 
>> appears that the only reliable solution is to shut down the server and 
>> reboot. So I would propose to support only dynamic changes the 
>> component can handle while running and not support changes which would 
>> need components to be restarted. The latter would have to be done 
>> offline then.
>>
>> Maybe there is a solution to this problem in some container we come up 
>> with. It's enough work to cope with simple configuration changes in 
>> the first place.
> 
> 
> Imho we should find a way to reconfiugre some of them.
> As an example I this we should be able to restart the SpoolManager 
> without restarting SMTPServer and POP3Server, restart the SMTPServer 
> without restarting the SpoolManager and so on.
> It would be really useful now that we also have fastfail to restart and 
> reconfigure SMTPServer or SpoolManager without having to restart the 
> whole server!
> Imho it should not be so difficult to do this at least for major 
> indipendend components (SpoolManager, SMTPServer, POP3Server, 
> RemoteManager...).

Certainly would be great to have it. Just want to make one step before 
the other.
We'll surely all get into a nice life(re)cycling discussion one sunny 
day. ;-)

> I also would really like to know what are the ideas of Peter Royal on 
> configuration. He worked on Avalon/Phoenix and he now works with OSGi so 
> I think he could give us really precious hints about this issue!

Should we put together some concrete questions for him?

   Bernd

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