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.
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.
When do we validate a configuration?
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).
- 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...).
- Configuration Mappers -
Let's introduce a bunch of Mapper objects, which are each able to take a
sub-Avalon-DefaultConfiguration, parse the Strings etc and inject the
specific data into the specific Configurable objects. When the avalon
configuration is eventually abandoned or deprecated, let's have another
bunch of Mappers for mapping from commons-configuration or whatever we
decide upon.
Let's not use those dumb ConfigContainers with no logic. The mappers
could also be the ConfigContainers. (I'd volunteer to refactor Postage
accordingly.)
Step by step we would move the access to DefaultConfiguration out of the
Configurables into specialized mapper classes.
I agree.
- JMX -
MBeans would more or less directly execute operations by using the
Configurable's setters and methods like it is done at present. They
would not necessarily use the configuration framework.
JMX is not good at internally exposing component management. Geronimo
has explicitly moved away from being a MBean-based kernel, JBoss kind of
suffers from being one.
The reason for that is that the intended JMX granularity (the way a
remote managing person would like to have it) often does not match with
the server-internal granularity of
Configurables/modules/components/classes.
JMX is good for being a remote 'high-level' API for management.
Let's go on with using JMX as we currently do, more or less.
I agree also on this.
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!
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
