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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
