Re: ModifiableConfiguration [ was "Porting dbXML to Avalon" ]

[Paul Hammant]

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]