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]
