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