Berin,
>>> cfg.getChild("somechild").getChild("anotherchild").getValueAsLong();
>>
>> setableCfg.getChild("somechild").getChild("anotherchild").setLongValue(14);
>
>
>Thanks for the refocusing comment above. My question
>is, "who is responsible for setting the
>configuration?"
>The point being, with the IoC pattern (see site docs
>for those not familiar), the Configuration is given as
>a read only instance for a reason. The Configurable
>Component is not supposed to alter the system beneath
>it in the Component heirarchy. With that in mind, we
>have to consider exactly what types of configuration
>changes are occuring, the affect on the system, and
>which component/service is responsible for altering
>the
>configuration.
>
Yes it's true that Configurable gived a read-only configuration, but if
the block......
1) implements ConfigurationModifier,
2) specifies which Configuration nodes it will be seeking to have
modification rights for, in it's assembly.xml,
3) is then handed a ModifiableConfiguration during startup,
4) call invoke getChild("x").getChild("y").setLongValue(14) on that
only, not it's own Configuration.
..... does that still break the IoC design goals?
>It is probable that the dbXML folks have thought many
>of these things through, so I am very interested in
>the approach and thought processes they have gone
>through for their system.
>
>It could be that we should develop a special purpose
>configuration management service that manages the
>persistence of the Configuration elements. In that
>case we programmatically build what we _want_ the
>configuration to be (i.e. the current method building
>configuration trees) and register it with the
>Configuration Management Service. The service would
>be an Avalon Block in CornerStone.
>
Sounds superior to the above...
- Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
