You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2001/09/18 16:38:28 UTC
Changes to Framework
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:
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.
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.
Persistable extends Configurable, and has only one method, "persist()"
that returns a Configuration object.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Changes to Framework
Posted by Berin Loritsch <bl...@apache.org>.
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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Changes to Framework
Posted by Peter Donald <do...@apache.org>.
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.
> 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.
> 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.
Management of configuration is a separate concern from reading of
configuration and should be treated as such IMHO.
--
Cheers,
Pete
-----------------------------------------------
"Only two things are infinite, the universe and
human stupidity, and I'm not sure about the
former." -Albert Einstein
-----------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Changes to Framework
Posted by Paul Hammant <Pa...@yahoo.com>.
Berin
>[ ... snip ... ]
>
"Persistable extends Configurable" (from commits)
I appreciate this is about Framework, which I'm less interested in that phoenix, but is Persisteable the right name (re-opening battles from last year). Would not PersistableConfigurable give a better clue to the casual reader of the code what it does? i.e. that it's to do with Configurable has been lost.
PS - It's great news that Axis is coming on leaps and bounds. Can you get a feel for when it might be up to the sort of level Glue is at? Might it be an alternative implementaiton of the Soapification service sometime soon?
Regards,
- Paul H
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org