On Fri, Sep 19, 2008 at 9:01 PM, Bernd Fondermann <[EMAIL PROTECTED]> wrote: > Robert Burrell Donkin wrote: >> >> On Mon, Sep 15, 2008 at 6:13 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: >>> >>> Robert Burrell Donkin ha scritto: >>>> >>>> 2 moving forward, would it be convenient to use an object model to >>>> decouple configuration from avalon? >>> >>> Maybe our only alternative... >> >> object models can sometimes be useful tools for documenting the >> configuration as well > > Do you mean a set of classes dedicated to hold only configuration info? > > if yes, I'm all for it. +1
a set of beans modelling the configuration based on the xml structure for example, the james block in configuration might be modelled by beans sketched (setters etc ignored) as follows: James public String getPostMaster() public boolean isVirtualHostingEnabled() public boolean getDefaultDomain() public HelloName getHelloName() HelloName public String getHelloName() public boolean isAutoDetectionEnabled() > I think this is one of the crucial (if not the single most important) things > to do to get away from intrusive containers. +1 maintaining configuration compatibility is important but we don't have a clear definition of that configuration other than the code itself > but accessing the current configuration as it is now is very tightly coupled > with business logic. moving away from it changes a lot of code and would > require loads of unit tests. i was wondering whether we could cover these changes by functional tests on packaged artifacts > maybe a dual model could make this work, one that on the one side behaves > like nice and friendly configuration objects with getters and on the other > side like our current tree-like generic configuration a la Avalon. the avalon configuration is a generic DOM. components walk this DOM and extract the configuration information they need. the advantage of generic DOMs is that they are very flexible and easy to change. this is also their biggest weakness. the james configuration has grown without definition or control. IMO this is a major problem going forward. the easiest move from a generic DOM should be to a strongly typed DOM. it should be possible to work through the code replacing generic DOM calls with a pair of calls to set the bean property from the avalon configuration and then get the value from the bean. the resulting object model would document and control the configuration supported. the risk of errors should be low. -- oOo --- i increasingly agree with the viewpoint that says the james server application needs to ship with a limited, heavily defaulted configuration with only settings that are understandable for administrators available. in the long term, i would like to consolidate everything onto a JCR. the default configuration shipped could run out of the box with embedded derby and jackrabbit and offer a complete shrink-wrapped solution. i think we need to prune from the main configuration a lot of the optional stuff. for example, i would prefer to see the fetchmail part of the main configuration deprecated and maintained only with a legacy compatibility layer. going forward, fetchmail would be loaded by a modern IoC mechanism. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
