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/29 14:49:35 UTC
[VOTE] RE: MutableConfiguration
I propose to:
1. add the following MutableConfiguration interface to framework
(see below).
2. Add the getMutableChild and getMutableChildren methods to
the DefaultConfiguration class.
3. Have DefaultConfiguration implement the MutableConfiguration
interface.
+1 from me.
package org.apache.avalon.framework.configuration;
/**
* A read/write extension of the Configuration interface.
*
* @author <a href="mailto:dev@avalon.apache.org">Avalon Development
Team</a>
* @version CVS $Revision: 1.27 $ $Date: 2003/02/11 15:58:38 $
*/
public interface MutableConfiguration extends Configuration
{
/**
* Set the value of this <code>Configuration</code> object to the
specified string.
*
* @param value a <code>String</code> value
*/
public void setValue( final String value );
/**
* Set the value of this <code>Configuration</code> object to the
specified int.
*
* @param value a <code>int</code> value
*/
public void setValue( final int value );
/**
* Set the value of this <code>Configuration</code> object to the
specified long.
*
* @param value a <code>long</code> value
*/
public void setValue( final long value );
/**
* Set the value of this <code>Configuration</code> object to the
specified boolean.
*
* @param value a <code>boolean</code> value
*/
public void setValue( final boolean value );
/**
* Set the value of this <code>Configuration</code> object to the
specified float.
*
* @param value a <code>float</code> value
*/
public void setValue( final float value );
/**
* Set the value of the specified attribute to the specified string.
*
* @param name name of the attribute to set
* @param value a <code>String</code> value
*/
public void setAttribute( final String name, final String value );
/**
* Set the value of the specified attribute to the specified int.
*
* @param name name of the attribute to set
* @param value an <code>int</code> value
*/
public void setAttribute( final String name, final int value );
/**
* Set the value of the specified attribute to the specified long.
*
* @param name name of the attribute to set
* @param value an <code>long</code> value
*/
public void setAttribute( final String name, final long value );
/**
* Set the value of the specified attribute to the specified
boolean.
*
* @param name name of the attribute to set
* @param value an <code>boolean</code> value
*/
public void setAttribute( final String name, final boolean value );
/**
* Set the value of the specified attribute to the specified float.
*
* @param name name of the attribute to set
* @param value an <code>float</code> value
*/
public void setAttribute( final String name, final float value );
/**
* Add a child <code>Configuration</code> to this configuration
element.
* @param configuration a <code>Configuration</code> value
*/
public void addChild( final Configuration configuration );
/**
* Add all the attributes, children and value
* from specified configuration element to current
* configuration element.
*
* @param other the {@link Configuration} element
*/
public void addAll( final Configuration other );
/**
* Add all attributes from specified configuration
* element to current configuration element.
*
* @param other the {@link Configuration} element
*/
public void addAllAttributes( final Configuration other );
/**
* Add all child <code>Configuration</code> objects from specified
* configuration element to current configuration element.
*
* @param other the other {@link Configuration} value
*/
public void addAllChildren( final Configuration other );
/**
* Remove a child <code>Configuration</code> to this configuration
element.
* @param configuration a <code>Configuration</code> value
*/
public void removeChild( final Configuration configuration );
/**
* Equivalent to <code>getMutableChild( name, true )</code>
*/
public MutableConfiguration getMutableChild( final String name );
/**
* Gets a child node of this configuration. If a mutable child with
the
* given name exists, it is returned. If an immutable child with the
* given name exists, it is converted into a mutable child and
returned.
* In this case, the immutable child will be replaced with the
mutable
* child in this configuration (that is, it will be as if the child
* node always had been mutable).
* If no child with the given name exists, and
<code>autoCreate</code>
* is <code>true</code>, a new mutable child is created and added to
* this configuration before being returned.
*
* @returns the child MutableConfiguration, or <code>null</code> if
<code>autoCreate</code>
* was false and no child by the given name existed.
* @param name the name of the child.
* @param autoCreate set to true to create the child node if it
doesn't exist.
*/
public MutableConfiguration getMutableChild( final String name,
boolean autoCreate );
/**
* Returns an array of mutable children with the given name.
Immutable children
* are converted just as for <code>getMutableChild</code>.
*/
public MutableConfiguration[] getMutableChildren( final String name
);
}
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [VOTE] RE: MutableConfiguration
Posted by Fernando Padilla <fe...@interdimensions.com>.
I have some comments, that might
On Thu, 29 Jan 2004, Niclas Hedhman wrote:
> On Thursday 29 January 2004 05:49, Leo Sutic wrote:
> > I propose to:
> >
> > 1. add the following MutableConfiguration interface to framework
> > (see below).
> >
> > 2. Add the getMutableChild and getMutableChildren methods to
> > the DefaultConfiguration class.
> >
> > 3. Have DefaultConfiguration implement the MutableConfiguration
> > interface.
> >
> > +1 from me.
>
> I vote "No".
>
> There has been a lot of talk of what to do and how to do it, but very little
> about WHY.
>
> IMHO, it is even a violation of IoC. My personal interpretation of IoC is
> "Here you go Mr Component, I have provided this for you, now live with it!"
>
>
> Why should the component be allowed to change its configuration object? If so,
> why should the component not be allowed to change its Logger, Dependencies
> and Contexts as well?
>
> Is it implied that the Container MUST, SHOULD or CAN persist that between JVM
> invocations?
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [VOTE] RE: MutableConfiguration
Posted by Stephen McConnell <mc...@apache.org>.
Leo Sutic wrote:
>
>>From: Niclas Hedhman [mailto:niclas@hedhman.org]
>>
>>On Thursday 29 January 2004 05:49, Leo Sutic wrote:
>>
>>>I propose to:
>>>
>>> 1. add the following MutableConfiguration interface to framework
>>> (see below).
>>>
>>> 2. Add the getMutableChild and getMutableChildren methods to
>>> the DefaultConfiguration class.
>>>
>>> 3. Have DefaultConfiguration implement the MutableConfiguration
>>> interface.
>>>
>>>+1 from me.
>>
>>I vote "No".
>
>
> I take that as a -1 VETO.
>
>
>>Why should the component be allowed to change its
>>configuration object?
>
>
> This has ***never*** been proposed. Nowhere have I *ever* stated
> that the MutableConfiguration should be passed in to the
> Component in the configure method, nor that it should be
> part of the Configurable contract, or any lifecycle contract
> at all.
However - the proposed addition of this to the framework API is
inconsistent with this position.
> In my original argument for this interface, I specifically
> state that this is ***NOT*** part of the proposal. If we,
> sometime in the future would like to pass in MutableConfigurations
> instead of Configurations, we sure can vote about that, but
> for now that's simply not an issue.
But placing the interface in framework API makes it an immediate and
present issue for me. In particular - adding something to the framework
API *implies* something in terms of the overall framework contract - and
implication that we cannot easily back away from once released.
> Argument is here:
> http://marc.theaimsgroup.com/?l=avalon-dev&m=107485031403277&w=2
>
>
>>"Here you go Mr Component, I have provided this for you, now
>>live with it!"
>
>
> "Here you go Mr Component, fill in your current configuration
> here."
>
> Scribble scribble scribble...
>
> "Thank you Mr Component."
This can archived independently of the framework API. Lets' assume the
Mr Component is handling the management of another component. Mr
Component gets log enabled, configured, serviced, etc. Part of the
servicing process is to supply Mr Component with a MutableConfiguration.
Perhaps Mr Component presents this via a web page where Mr User
changes things. Mr Component then interacts via a MutableConfiguration
interface to propagate changes.
The important point here is that we are not discussing framework aspects
- we are discussing a separate and distinct service - and this directly
impacts on the question concerning the location of this service
interface and potential implementations of that interface.
Stephen.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: No Vetoes? (was: Re: [VOTE] RE: MutableConfiguration)
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tuesday 03 February 2004 00:48, Leo Simons wrote:
> > b. I like democratic rules better.
>
> I don't. Striving for consensus reduces the importance of voting. We can
> have something like "lazy consensus", but "lazy democracy" doesn't work
> too well (Re: the USA).
Well, United Nation's Security Council was paralyzed for 50years because of
Vetos.
But in any event, I have consumed your (and otthers' ) thoughts and will try
my best to apply them from time to time.
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
No Vetoes? (was: Re: [VOTE] RE: MutableConfiguration)
Posted by Leo Simons <le...@apache.org>.
Niclas Hedhman wrote:
> IMHO,
> a. It is unclear when "consensus is required".
preferably, always. If consensus cannot be reached, consensus should be
reached on how to proceed. If consensus is not reached quite often on
some kinds of issues, consensus can be reached on deviation from the
basic consensus rule (ie, as we did with the Avalon PMC voting guidelines).
> b. I like democratic rules better.
I don't. Striving for consensus reduces the importance of voting. We can
have something like "lazy consensus", but "lazy democracy" doesn't work
too well (Re: the USA).
Anyway, if we want we can change rules, add them, remove them, whatever.
But my preferred alternative is to just not debate small issues at
length and apply meritocracy and lazy consensus principles (ie we
recognize a particular issue is not worth three weeks of discussion so
we just move forward and get out of the way of the people doing the work).
Put yet another way: if an issue is not important enough to want to
achieve consensus, its not important enough to hold a vote :D
----
Leo Sutic wrote: "Raise the issue on the PMC mailing list"
nah, let's keep the conversation public :D
--
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
RE: [VOTE] RE: MutableConfiguration
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Niclas Hedhman [mailto:niclas@hedhman.org]
>
> a. It is unclear when "consensus is required".
From: http://jakarta.apache.org/site/decisions.html
"All product changes to the currently active repository are
subject to lazy consensus."
Thus -1 == VETO. Hope that cleared it up.
> b. I like democratic rules better.
Raise the issue on the PMC mailing list, and we'll see what
can/should be done. I don't think we should include that
discussion in this vote, however.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [VOTE] RE: MutableConfiguration
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Monday 02 February 2004 23:34, Leo Sutic wrote:
> > From: Niclas Hedhman [mailto:niclas@hedhman.org]
> > What should I vote if I mean; "I am against it, but will
> > accept a majority
> > (more positive than negative, not counting impartial, votes)
> > decision in the
> > issue." ??
>
> You should vote -0.
From; http://jakarta.apache.org/site/decisions.html
+1
"Yes," "Agree," or "the action should be performed." On some issues this is
only binding if the voter has tested the action on their own system(s).
+/-0
"Abstain," "no opinion". An abstention may have detrimental effects if too
many people abstain.
-1
"No." On issues where consensus is required, this vote counts as a veto. All
vetos must contain an explanation of why the veto is appropriate. Vetos with
no explanation are void. No veto can be overruled. If you disagree with the
veto, you should lobby the person who cast the veto. Voters intending to veto
an action item should make their opinions known to the group immediately so
that the problem can be remedied as early as possible.
IMHO,
a. It is unclear when "consensus is required".
b. I like democratic rules better.
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [VOTE] RE: MutableConfiguration
Posted by Jonathan Hawkes <jh...@adsnm.com>.
How about (-1)^2
:)
----- Original Message -----
From: "Leo Sutic" <le...@inspireinfrastructure.com>
To: "'Avalon Developers List'" <de...@avalon.apache.org>
Sent: Monday, February 02, 2004 8:34 AM
Subject: RE: [VOTE] RE: MutableConfiguration
>
>
> > From: Niclas Hedhman [mailto:niclas@hedhman.org]
> >
> > On Friday 30 January 2004 18:22, Leo Sutic wrote:
> > > > I vote "No".
> > >
> > > I take that as a -1 VETO.
> >
> > What should I vote if I mean; "I am against it, but will
> > accept a majority
> > (more positive than negative, not counting impartial, votes)
> > decision in the
> > issue." ??
>
> You should vote -0.
>
> /LS
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [VOTE] RE: MutableConfiguration
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Niclas Hedhman [mailto:niclas@hedhman.org]
>
> On Friday 30 January 2004 18:22, Leo Sutic wrote:
> > > I vote "No".
> >
> > I take that as a -1 VETO.
>
> What should I vote if I mean; "I am against it, but will
> accept a majority
> (more positive than negative, not counting impartial, votes)
> decision in the
> issue." ??
You should vote -0.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [VOTE] RE: MutableConfiguration
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 30 January 2004 18:22, Leo Sutic wrote:
> > I vote "No".
>
> I take that as a -1 VETO.
What should I vote if I mean; "I am against it, but will accept a majority
(more positive than negative, not counting impartial, votes) decision in the
issue." ??
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [VOTE] RE: MutableConfiguration
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Niclas Hedhman [mailto:niclas@hedhman.org]
>
> On Thursday 29 January 2004 05:49, Leo Sutic wrote:
> > I propose to:
> >
> > 1. add the following MutableConfiguration interface to framework
> > (see below).
> >
> > 2. Add the getMutableChild and getMutableChildren methods to
> > the DefaultConfiguration class.
> >
> > 3. Have DefaultConfiguration implement the MutableConfiguration
> > interface.
> >
> > +1 from me.
>
> I vote "No".
I take that as a -1 VETO.
> Why should the component be allowed to change its
> configuration object?
This has ***never*** been proposed. Nowhere have I *ever* stated
that the MutableConfiguration should be passed in to the
Component in the configure method, nor that it should be
part of the Configurable contract, or any lifecycle contract
at all.
In my original argument for this interface, I specifically
state that this is ***NOT*** part of the proposal. If we,
sometime in the future would like to pass in MutableConfigurations
instead of Configurations, we sure can vote about that, but
for now that's simply not an issue.
Argument is here:
http://marc.theaimsgroup.com/?l=avalon-dev&m=107485031403277&w=2
> "Here you go Mr Component, I have provided this for you, now
> live with it!"
"Here you go Mr Component, fill in your current configuration
here."
Scribble scribble scribble...
"Thank you Mr Component."
> Is it implied that the Container MUST, SHOULD or CAN persist
> that between JVM invocations?
Since it isn't part of any contract in framework, the container
can do as it pleases.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [VOTE] RE: MutableConfiguration
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 29 January 2004 05:49, Leo Sutic wrote:
> I propose to:
>
> 1. add the following MutableConfiguration interface to framework
> (see below).
>
> 2. Add the getMutableChild and getMutableChildren methods to
> the DefaultConfiguration class.
>
> 3. Have DefaultConfiguration implement the MutableConfiguration
> interface.
>
> +1 from me.
I vote "No".
There has been a lot of talk of what to do and how to do it, but very little
about WHY.
IMHO, it is even a violation of IoC. My personal interpretation of IoC is
"Here you go Mr Component, I have provided this for you, now live with it!"
Why should the component be allowed to change its configuration object? If so,
why should the component not be allowed to change its Logger, Dependencies
and Contexts as well?
Is it implied that the Container MUST, SHOULD or CAN persist that between JVM
invocations?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org