You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@avalon.apache.org by le...@apache.org on 2004/01/29 17:27:39 UTC

cvs commit: avalon/framework/api/src/java/org/apache/avalon/framework/configuration MutableConfiguration.java

leosutic    2004/01/29 08:27:39

  Added:       framework/api/src/java/org/apache/avalon/framework/configuration
                        MutableConfiguration.java
  Log:
  Added a MutableConfiguration interface.
  
  Revision  Changes    Path
  1.1                  avalon/framework/api/src/java/org/apache/avalon/framework/configuration/MutableConfiguration.java
  
  Index: MutableConfiguration.java
  ===================================================================
  /*
   * Copyright 1997-2004 Apache Software Foundation
   * 
   * Licensed under the Apache License, Version 2.0 (the "License");
   * you may not use this file except in compliance with the License.
   * You may obtain a copy of the License at
   * 
   *     http://www.apache.org/licenses/LICENSE-2.0
   * 
   * Unless required by applicable law or agreed to in writing, software
   * distributed under the License is distributed on an "AS IS" BASIS,
   * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   * See the License for the specific language governing permissions and
   * limitations under the License.
   */
  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.1 $ $Date: 2004/01/29 16:27:39 $
   */
  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. If null, the attribute is removed.
       */
      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 ) throws ConfigurationException;
      
      /**
       * 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.
       * @throws ConfigurationException if an error occurrs.
       */
      public MutableConfiguration getMutableChild( final String name, boolean autoCreate ) throws ConfigurationException;
      
      /**
       * Returns an array of mutable children. Immutable children
       * are converted just as for <code>getMutableChild</code>.
       * @throws ConfigurationException if an error occurrs.
       */
      public MutableConfiguration[] getMutableChildren() throws ConfigurationException;
      
      /**
       * Returns an array of mutable children with the given name. Immutable children
       * are converted just as for <code>getMutableChild</code>.
       * @throws ConfigurationException if an error occurrs.
       */
      public MutableConfiguration[] getMutableChildren( final String name ) throws ConfigurationException;
  }
  
  
  

---------------------------------------------------------------------
To unsubscribe, e-mail: cvs-unsubscribe@avalon.apache.org
For additional commands, e-mail: cvs-help@avalon.apache.org


Re: cvs commit: avalon/framework/api/src/java/org/apache/avalon/framework/configuration MutableConfiguration.java

Posted by Leo Simons <le...@apache.org>.
Niclas Hedhman wrote:
>  proper due process.

bleh. Let's not let ourself get hampered by "proper due process" unless 
its got something to do with "due diligence", legalities, or anything 
like that. Let's focus on getting work done.

-- 
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


configuration packaging

Posted by Stephen McConnell <mc...@apache.org>.
Leo Sutic wrote:

> 
>>From: Stephen McConnell [mailto:mcconnell@apache.org] 
>>
>>What I propose is a package in avalon vs named avalon-configuration
>>
>>   avalon/avalon-configuration
>>     api  <--- contains MutableConfiguration
>>     impl <--- contains DefaultConfiguration
>>               contains DefaultMultipleConfiguration
>>               and possibly the rest of the content currently
>>               under framework/impl/.../configuration
>>
>>... then we have a clear separation of the container side concerns 
>>relating to configuration as distinct from the container/component 
>>contract concerns that are dealt with under the framework space.
> 
> 
> I oppose an avalon-configuration package. However, abstracting one level
> up may be required.


OK ... but relative to location this implies

    avalon/xxxx

or

    xxx


> It seems like we have three types of things under
> org.apache.avalon.framework:
> 
>  1. Lifecycle contracts and supporting interfaces: Such as
> Initializable,
>     Configurable, Configuration, etc. Basically the interfaces and
> classes
>     involved in getting a component good to go, and decomissioning.

yep

>  2. Default implementations of the interfaces in (1), and utility
> classes:
>     DefaultConfiguration, DefaultConfigurationBuilder, 
>     DefaultConfiguration, DefaultContext, etc.

and so log as these remain realistic default implementations these make 
sense - and in the scenario of this thread we are talking about the 
introduction of an implementation contract which is below the api and 
above the implementation

>  3. Additional interfaces: Abstractions of default implementations such
> as
>     MutableConfiguration. To understand what I mean by this, consider a
> world
>     where we have java.util.ArrayList, but no java.util.List. Then
> someone 
>     thinks: "Hmmm. An ArrayList is just an implementation of a List. We
> should
>     perhaps define such an interface." That's my thought about
> DefaultConfiguration/
>     MutableConfiguration.

I understand this completely.  The question I have concerns the 
relevance of DefaultConfiguration to this discussion. IMO 
DefaultConfiguration is simply an unqualified implementation example.


> What makes this such a mess is that we have (2) under
> org.apache.avalon.framework!
> (2) are basically utility classes - none of them figure in any lifecycle
> contract,
> which really makes them not part of framework. You can write a source
> and binary
> compatible container without ever using them.

Which is the reason why this needs to be resolved properly. Take for 
example the stuff I'm doing on the avalon-logging package .. its 
replacing classes in avalon-framework/impl because the impl is 
structured.  I see direct and immediate parallels between this and the 
concerns relative to configuration.

> And since we have implementations in framework, (3) pretty much has to
> go there 
> as well.

On this I disagree.
We can create org.apache.avalon.configuration and include withing this 
namespace the things that really make sense as pertains to the question 
of configuration implementation strategies.


> What we should have done is:
> 
>  1. org.apache.avalon.lifecycle
> 
>  2. org.apache.avalon.util
> 
>  3. org.apache.avalon.util
> 
> (Note that I don't propose the above.)
> 
> But now we're stuck with what we have - we have implementation and
> supporting classes 
> in the same java package as the interfaces. I can understand the
> implementation 
> classes but not the support classes. I mean, would you put
> SAXConfigurationBuilder into
> org.apache.avalon.framework.configuration today if you had a choice?
> Moving classes 
> around packages is suicide at the moment, so we're sorta stuck with what
> we have.

I disagree - the APIs are contact - what we do with the impl is another 
question.  Create fred.xyz.DefaultConfiguration - does not matter - it 
does not impact the framework contract spec.

> So instead of having:
> 
>   avalon-framework-api
>   avalon-framework-impl
>   avalon-framework-configuration
> 
> perhaps:
> 
>   avalon-framework-api                 << Configurable, Configuration
>   avalon-framework-xapi (eXtended-API) << MutableConfiguration
>   avalon-framework-impl                << DefaultConfiguration, 
>                                           DefaultConfigurationBuilder

What is the difference with the above and :

   avalon-framework-api
   avalon-configuration-api <-- container side apis
   avalon-configuration-impl <-- implementations

or

   avalon-configuration-xml <-- implementations


The difference is that your not saying that something is part of the 
component/container contract ... instead your saying ... "relative to 
the container/component contract there is an implementation solution".

> 
> Dependencies are: impl depends on xapi depends on api.

I understand (and agree) except for the "framework" aspect ... because 
its not actually framework .. its just an implementation strategy that 
happens to have an interface associated with it.

Stephen.


> /LS
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
> 
> 


-- 

|------------------------------------------------|
| 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: cvs commit: avalon/framework/api/src/java/org/apache/avalon/framework/configuration MutableConfiguration.java

Posted by Leo Sutic <le...@inspireinfrastructure.com>.

> From: Stephen McConnell [mailto:mcconnell@apache.org] 
>
> What I propose is a package in avalon vs named avalon-configuration
> 
>    avalon/avalon-configuration
>      api  <--- contains MutableConfiguration
>      impl <--- contains DefaultConfiguration
>                contains DefaultMultipleConfiguration
>                and possibly the rest of the content currently
>                under framework/impl/.../configuration
> 
> ... then we have a clear separation of the container side concerns 
> relating to configuration as distinct from the container/component 
> contract concerns that are dealt with under the framework space.

I oppose an avalon-configuration package. However, abstracting one level
up may be required.

It seems like we have three types of things under
org.apache.avalon.framework:

 1. Lifecycle contracts and supporting interfaces: Such as
Initializable,
    Configurable, Configuration, etc. Basically the interfaces and
classes
    involved in getting a component good to go, and decomissioning.

 2. Default implementations of the interfaces in (1), and utility
classes:
    DefaultConfiguration, DefaultConfigurationBuilder, 
    DefaultConfiguration, DefaultContext, etc.

 3. Additional interfaces: Abstractions of default implementations such
as
    MutableConfiguration. To understand what I mean by this, consider a
world
    where we have java.util.ArrayList, but no java.util.List. Then
someone 
    thinks: "Hmmm. An ArrayList is just an implementation of a List. We
should
    perhaps define such an interface." That's my thought about
DefaultConfiguration/
    MutableConfiguration.

What makes this such a mess is that we have (2) under
org.apache.avalon.framework!
(2) are basically utility classes - none of them figure in any lifecycle
contract,
which really makes them not part of framework. You can write a source
and binary
compatible container without ever using them.

And since we have implementations in framework, (3) pretty much has to
go there 
as well.

What we should have done is:

 1. org.apache.avalon.lifecycle

 2. org.apache.avalon.util

 3. org.apache.avalon.util

(Note that I don't propose the above.)

But now we're stuck with what we have - we have implementation and
supporting classes 
in the same java package as the interfaces. I can understand the
implementation 
classes but not the support classes. I mean, would you put
SAXConfigurationBuilder into
org.apache.avalon.framework.configuration today if you had a choice?
Moving classes 
around packages is suicide at the moment, so we're sorta stuck with what
we have.

So instead of having:

  avalon-framework-api
  avalon-framework-impl
  avalon-framework-configuration

perhaps:

  avalon-framework-api                 << Configurable, Configuration
  avalon-framework-xapi (eXtended-API) << MutableConfiguration
  avalon-framework-impl                << DefaultConfiguration, 
                                          DefaultConfigurationBuilder

Dependencies are: impl depends on xapi depends on api.

/LS



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Re: cvs commit: avalon/framework/api/src/java/org/apache/avalon/framework/configuration MutableConfiguration.java

Posted by Stephen McConnell <mc...@apache.org>.
Leo Sutic wrote:
> 
>>From: Stephen McConnell [mailto:mcconnell@apache.org] 
>>
>>Please note that I'm not against the interface as such - its the 
>>interface in framework that I'm uncomfortable with and interface in 
>>framework API that I am opposed to at this time.
> 
> 
> So where do we put it?

I understand the problem and I have a proposal.

> Anywhere else but framework means that DefaultConfiguration *can't*
> be a MutableConfiguration, since that would imply that framework
> is dependent on some other avalon module.
> 
> If DefaultConfiguration can't me a MutableConfiguration, then
> the most commonly used configuration that is mutable isn't a
> MutableConfiguration.
> 
> Having it in framework-impl is bad because we then have interface
> and impl (DefaultConfiguration) in one jar.
> 
> Unless you want to create a third jar, and have framework impl
> depend on that one as well, it has to be in framework-api due to force 
> majeure.

What I propose is a package in avalon vs named avalon-configuration

   avalon/avalon-configuration
     api  <--- contains MutableConfiguration
     impl <--- contains DefaultConfiguration
               contains DefaultMultipleConfiguration
               and possibly the rest of the content currently
               under framework/impl/.../configuration

... then we have a clear separation of the container side concerns 
relating to configuration as distinct from the container/component 
contract concerns that are dealt with under the framework space.

However - getting something like this together in sandbox first of all 
would be really beneficial.  In fact it would let us rationalize the the 
avalon framework impl, excalibur configuration content and your stuff 
into a single well defined package.

Stephen.


> /LS
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
> 
> 


-- 

|------------------------------------------------|
| 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: cvs commit: avalon/framework/api/src/java/org/apache/avalon/framework/configuration MutableConfiguration.java

Posted by Leo Sutic <le...@inspireinfrastructure.com>.
OK, rolled back everything.

/LS


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


RE: cvs commit: avalon/framework/api/src/java/org/apache/avalon/framework/configuration MutableConfiguration.java

Posted by Leo Sutic <le...@inspireinfrastructure.com>.

> From: Stephen McConnell [mailto:mcconnell@apache.org] 
> 
> Please note that I'm not against the interface as such - its the 
> interface in framework that I'm uncomfortable with and interface in 
> framework API that I am opposed to at this time.

So where do we put it?

Anywhere else but framework means that DefaultConfiguration *can't*
be a MutableConfiguration, since that would imply that framework
is dependent on some other avalon module.

If DefaultConfiguration can't me a MutableConfiguration, then
the most commonly used configuration that is mutable isn't a
MutableConfiguration.

Having it in framework-impl is bad because we then have interface
and impl (DefaultConfiguration) in one jar.

Unless you want to create a third jar, and have framework impl
depend on that one as well, it has to be in framework-api due to force 
majeure.

/LS


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Re: cvs commit: avalon/framework/api/src/java/org/apache/avalon/framework/configuration MutableConfiguration.java

Posted by Stephen McConnell <mc...@apache.org>.
Leo Sutic wrote:
> 
>>From: Stephen McConnell [mailto:mcconnell@apache.org] 
>>
>>There is an existing VETO against this change.
>>
>>http://marc.theaimsgroup.com/?l=avalon-dev&m=107480523229097&w=2
> 
> 
> That veto was cast in another vote, and the general consensus
> was that more discussion was needed - not that the proposal was
> inherently flawed. I canceled that vote, and therefore any veto
> cast then has no meaning for this vote.
> 
> Nevertheless, I count this reminder as your valid -1 for the 
> change.

Thanks.

Please note that I'm not against the interface as such - its the 
interface in framework that I'm uncomfortable with and interface in 
framework API that I am opposed to at this time.

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: cvs commit: avalon/framework/api/src/java/org/apache/avalon/framework/configuration MutableConfiguration.java

Posted by Leo Sutic <le...@inspireinfrastructure.com>.

> From: Stephen McConnell [mailto:mcconnell@apache.org] 
>
> There is an existing VETO against this change.
> 
> http://marc.theaimsgroup.com/?l=avalon-dev&m=107480523229097&w=2

That veto was cast in another vote, and the general consensus
was that more discussion was needed - not that the proposal was
inherently flawed. I canceled that vote, and therefore any veto
cast then has no meaning for this vote.

Nevertheless, I count this reminder as your valid -1 for the 
change.

> Could you please rollback the changes 

Rolling them back.

/LS


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Re: cvs commit: avalon/framework/api/src/java/org/apache/avalon/framework/configuration MutableConfiguration.java

Posted by Stephen McConnell <mc...@apache.org>.
Leo:

There is an existing VETO against this change.

http://marc.theaimsgroup.com/?l=avalon-dev&m=107480523229097&w=2

Could you please rollback the changes and then put something together in 
sandbox.  Please note that I am not opposed to the interface itself - 
but I have serious concerns about introducing this into the framework API.

Stephen.


Leo Sutic wrote:

> 
>>From: Niclas Hedhman [mailto:niclas@hedhman.org] 
>>
>>On Thursday 29 January 2004 08:27, leosutic@apache.org wrote:
>>
>>>leosutic    2004/01/29 08:27:39
>>>
>>>  Added:      
>>>framework/api/src/java/org/apache/avalon/framework/configuration
>>>MutableConfiguration.java
>>>  Log:
>>>  Added a MutableConfiguration interface.
>>
>>WTF is going on now????
> 
> 
> This:
> 
> One week ago I proposed the MutableConfiguration interface.
> 
> Then everyone basically said that they wanted to discuss it more
> before going for a vote. 
> 
> So I stopped the premature vote and started a discussion.
> 
> That discussion went for a day or so, and then everybody stopped
> talking about it.
> 
> So I asked if anyone had anything more to say, or if we were good
> to go for a vote. The response I got indicated that we were.
> 
> So I moved to [vote], got the +3/-0 I needed, and implemented.
> 
> 
>>Feel free to fool around in the sandbox, but I feel this 
>>being a bit invasive without proper due process.
> 
> 
> OK, so what is due process?
> 
> You've had *one week* to post comments, ask questions, etc.
> 
> Like I said, throw your -1 VETO, and I'll roll back the changes.
> 
> But then I expect a motivation for your -1, and I expect you to 
> *participate* in the following discussion this time.
> 
> Fair enough?
> 
> /LS
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
> 
> 


-- 

|------------------------------------------------|
| 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: cvs commit: avalon/framework/api/src/java/org/apache/avalon/framework/configuration MutableConfiguration.java

Posted by Leo Sutic <le...@inspireinfrastructure.com>.

> From: Niclas Hedhman [mailto:niclas@hedhman.org] 
> 
> On Thursday 29 January 2004 08:27, leosutic@apache.org wrote:
> > leosutic    2004/01/29 08:27:39
> >
> >   Added:      
> > framework/api/src/java/org/apache/avalon/framework/configuration
> > MutableConfiguration.java
> >   Log:
> >   Added a MutableConfiguration interface.
> 
> WTF is going on now????

This:

One week ago I proposed the MutableConfiguration interface.

Then everyone basically said that they wanted to discuss it more
before going for a vote. 

So I stopped the premature vote and started a discussion.

That discussion went for a day or so, and then everybody stopped
talking about it.

So I asked if anyone had anything more to say, or if we were good
to go for a vote. The response I got indicated that we were.

So I moved to [vote], got the +3/-0 I needed, and implemented.

> Feel free to fool around in the sandbox, but I feel this 
> being a bit invasive without proper due process.

OK, so what is due process?

You've had *one week* to post comments, ask questions, etc.

Like I said, throw your -1 VETO, and I'll roll back the changes.

But then I expect a motivation for your -1, and I expect you to 
*participate* in the following discussion this time.

Fair enough?

/LS


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Re: cvs commit: avalon/framework/api/src/java/org/apache/avalon/framework/configuration MutableConfiguration.java

Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 29 January 2004 08:27, leosutic@apache.org wrote:
> leosutic    2004/01/29 08:27:39
>
>   Added:      
> framework/api/src/java/org/apache/avalon/framework/configuration
> MutableConfiguration.java
>   Log:
>   Added a MutableConfiguration interface.

WTF is going on now????

Something went from a VOTE into [Too Early] and has now went into the 
Framework API !!!!

Feel free to fool around in the sandbox, but I feel this being a bit invasive 
without proper due process.

Niclas



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org