Peter Donald wrote:
>
> Hi,
>
> Just fore reference I think I would prefer that this be placed in a proposal
> dir until it has been tested a bit more.
>
> On Wed, 19 Sep 2001 00:38, Berin Loritsch wrote:
> > I just added a Persistable interface so that Components that may
> > change their configuration parameters during run-time will be able
> > to save those changes to the configuration file. Here is where it
> > will really help:
>
> I think Persistable is probably the wrong term for this as it sounds too
> generic.
Perhaps--but I need something that works. The context is persistent configuration.
If you have a better name, let me know. (What about "Restorable"?).
> > ExcaliburComponentManager/Selector classes can be modified to be
> > persistable, and perform self-tuning. In other words, the magic
> > parameters for pool sizes on Poolable Components can be altered
> > to what the last maximum number of concurrent components in the
> > pool were. It can also calculate the most efficient grow size
> > and minimum components by an algorithm. With that done, the
> > persistable interface will automagically plant those attributes
> > as it gives returns its Configuration object.
>
> Thats fine but currently we have no mechanism to modify the Configuration
> object and thus I can't see any use of persist() currently.
We have DefaultConfiguration, so we can either build the configuration
fresh, or we can decide on a ModifiableConfiguration.
> > It also allows for self-healing configuration files so that as
> > a deprecated Configuration parameter is read in and handled, the
> > current prefered parameters are persisted.
> >
> > I came up with this approach due to both the dialogue with the
> > dbXML folks, and the way that Axis needs to handle persistance.
> > Axis can add new Handlers, etc. during the normal life cycle, and
> > we need to reflect that in the Configuration.
>
> I agree that it is a desirable feature but I think it should be a separate
> *service* from Configurable interface. Maybe we have a ConfigurationStore or
> ConfigurationRepository or whatever that we can get ModifiableConfiguration
> (or MutableConfiguration) objects that we can alter later or whatever.
The advantage of this approach is the Cascading affect of this. In other
words, each Component handles it's own configuration--and passes on the
configuration to the manager.
> Management of configuration is a separate concern from reading of
> configuration and should be treated as such IMHO.
Yes, but the management service needs a method of getting the configuration.
This provides a scalable method where configuration format is controlled by
the component.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
