Steve Brewin wrote:
Steve Brewin wrote:
See attached component diagram. Obviously I can elaborate to
Class diagrams
if required.
All, please remember, this is just one way to solve the problem and is
posted for discussion.
If I understood the diagram you are for using simple java beans as
configuration object (or even interfaces like we already do with
protocol handlers or with the fetchmail configuration) and refactor our
components to use a setConfiguration(ComponentConfigurationBean conf)
instead of the avalon configure(Configuration conf).
Then you would use an Mbean implementation using CommonsConfiguration
(possibly mutable configurations) for the load/save operations.
This is clean and I like it, but maybe this works fine only for top
level components and not for generated components.
How would you handle the SMTP Command Handler configuration, for example?
Currently the SMTPHandlerChain read the Avalon's Configuration received
and look for "handler" sub-configuration. The handlers are Configurable
objects and they know how to load their own configuration.
If SMTPHandlerChain received a Bean and not a hierarchical Configuration
object this would not be possible if you don't want to read and evaluate
the handlers configuration when you instantiate the first top level
component.
Currently we have 11 classes (excluding tests) using the
"ContainerUtil.configure(" method: This means that in 11 instances we
directly delegate the configuration to a child object (like the example
I did for SMTPHandlerChain).
To apply the pattern you proposed we have to find out a solution for
each of this 11 specific use of the Configuration object.
2 on 11 are not a problem: POP3Server and SMTPServer. But we want to
remove the usage of a hierarchical Configuration object (being it Avalon
Configuration or the direct use of Commons' HiearchicalConfiguration) we
should refactor the other 9.
The analysis of the 9 solutions is too much for this discussion: I will
concentrate on the SMTPHandlerChain issue I spotted before. Have you any
proposal on that?
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
