You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Sutic <le...@inspireinfrastructure.com> on 2004/01/22 18:05:00 UTC
MutableConfiguration interface
All,
I've done some experimentation with persisting a component's
configuration.
First, I started like this:
interface Persistable {
Configuration getConfiguration ();
}
but then I came upon the little snag that the container may want to add
more
configuration information to the Configuration before it is stored. So I
did this:
interface Persistable {
DefaultConfiguration getConfiguration ();
}
Then this:
interface Persistable {
void getConfiguration (DefaultConfiguration config);
}
which allowed the component to fill in its attributes etc.
But that's quite ugly.
So I'd like to have an interface - MutableConfiguration that will
extend Configuration, but add the mutators from DefaultConfiguration -
setAttribute, addChild, etc. DefaultConfiguration would then implement
this interface.
What do you think?
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: MutableConfiguration interface
Posted by hammett <ha...@uol.com.br>.
----- Original Message -----
From: "Cameron Fieber" <ca...@gems6.gov.bc.ca>
To: "Avalon Developers List" <de...@avalon.apache.org>
> On Thu, 2004-01-22 at 14:52, Leo Simons wrote:
> <snip>
> > (the main concern I have is in fact that Joe User may think that
> > components modifying their own config is a good idea in general; and I
> > don't think that's the case)
> </snip>
Thats certainly a not desirable side effect.
> Joe User here ;-)
Don't get us wrong. As a matter of fact our users should dictate our
feature. Who gives a thing for a nice project with no users?
> When you have the management capabilities that exist through JMX
> interfaces in Phoenix, or whatever instrumentation equivalent exists in
> Merlin, you end up with components that can get reconfigured on the fly
> through their management interface.
I'm not aware of that. Hows this configuration-management happens? Through
'set' methods or changing the Configuration (DefaultConfiguration) data and
reapplying it?
> To avoid losing that configuration, it has to be persisted somehow, and
> this Persistable interface seems much cleaner than how I've ended up
> solving the same problem in the past (which was basically creating my
> own DefaultConfiguration, and serializing it in the block home using the
> DefaultConfigurationSerializer, and reading it back on a call to
> configure).
Should the Configuration state be persisted or the component current state?
In Merlin a lifecycle extension could easily be added to handle the
persistence of component state. Which is the near from *the correct*
approach?
regards,
hammett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: MutableConfiguration interface
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 22 January 2004 15:54, Cameron Fieber wrote:
> On Thu, 2004-01-22 at 14:52, Leo Simons wrote:
> Joe User here ;-)
Hi Joe ;o)
Thanks for your very valid feedback.
> When you have the management capabilities that exist through JMX
> interfaces in Phoenix, or whatever instrumentation equivalent exists in
> Merlin, you end up with components that can get reconfigured on the fly
> through their management interface.
This is a very valid use-case, but it is not part of the container-component
contract. It is a container-management contract, which is not the scope of
Avalon Framework.
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: MutableConfiguration interface
Posted by Cameron Fieber <ca...@gems6.gov.bc.ca>.
On Thu, 2004-01-22 at 14:52, Leo Simons wrote:
<snip>
> (the main concern I have is in fact that Joe User may think that
> components modifying their own config is a good idea in general; and I
> don't think that's the case)
</snip>
Joe User here ;-)
When you have the management capabilities that exist through JMX
interfaces in Phoenix, or whatever instrumentation equivalent exists in
Merlin, you end up with components that can get reconfigured on the fly
through their management interface.
To avoid losing that configuration, it has to be persisted somehow, and
this Persistable interface seems much cleaner than how I've ended up
solving the same problem in the past (which was basically creating my
own DefaultConfiguration, and serializing it in the block home using the
DefaultConfigurationSerializer, and reading it back on a call to
configure).
To me its not so much about the component modifying its config as it is
about the config being modifiable through the components management
interfaces.
Regards,
-Cameron
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: MutableConfiguration interface
Posted by Leo Simons <le...@apache.org>.
Leo Sutic wrote:
> I've done some experimentation with persisting a component's
> configuration.
<snip/>
I vaguely recall solving something like this (and context persistence
and even dependency persistence (before we something like metadata was
formalized)) using a listener-style approach. With phoenix 3.0 alpha 3,
or somethin'. A stored procedure triggered a configuration change which
some set of kernel services merged with the config stored for the
component, then reloaded the whole block gracefully. Hmm.....
Have you tried anything like that? IMHO components should not change
their configuration, by contract. If the configuration is changed by an
external party, its nicest if you can just reload the component with the
new config. Of course, that requires that you can make the container
aware of the third party that wants to make the changes.
What about a lifecycle extension and/or a callback mechanism? Tried any
of those?
I understand those may be a little more complex than a mutable
configuration object, but like I said, I'm a bit weary of the concept of
components being in control of their own configuration. It breaks IoC,
and sounds like it could break security too.
> interface Persistable {
> Configuration getConfiguration ();
> }
>
> but then I came upon the little snag that the container may want to
> add more configuration information to the Configuration before it is
> stored.
so why doesn't the container use the provided configuration as a base?
In code:
componentProvidedConfig = persistable.getConfiguration();
checkComponentProvidedConfigIsValid( componentProvidedConfig );
finalConfig = ConfigurationUtil.merge( componentProvidedConfig,
customContainerConfig );
persistComponent( persistable, finalConfig, otherStuff )
man, this feels like deja vu. I'm sure we talked about it before...
<snip/>
> But that's quite ugly.
agreed.
> What do you think?
I'd like to see the case made that alternative methods really don't work
before we put it in framework...
...If we do put it in it should be made clear that components SHOULD NOT
ever attempt to cast the configuration past in through Configurable into
a MutableConfiguration as they MAY NOT modify that configuration.
(the main concern I have is in fact that Joe User may think that
components modifying their own config is a good idea in general; and I
don't think that's the case)
--
cheers,
- Leo Simons
-----------------------------------------------------------------------
Weblog -- http://leosimons.com/
IoC Component Glue -- http://jicarilla.org/
Articles & Opinions -- http://articles.leosimons.com/
-----------------------------------------------------------------------
"We started off trying to set up a small anarchist community, but
people wouldn't obey the rules."
-- Alan Bennett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org