You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Mircea Toma <mi...@home.com> on 2001/09/12 01:02:39 UTC
Configuration management
Hi,
To change the Configuration at runtime we need a ModifiableConfiguration (I
know that there were some discussions about this) in this way I can have the
management written against a interface not a class. I guess the interface is
straight forward since this functionality is implemented by the
DefaultConfiguration:
public interface ModifiableConfiguration extends Configuration
{
void addChild( final Configuration configuration );
void removeChild( final Configuration configuration );
void setAttribute( final String name, final String value );
void setValue( final String value );
void makeReadOnly();
}
The next issue on *the list* is that I'm not sure how should I implement the
configuration management, until now I have two solutions:
1) Have a Dynamic that wraps each Configuration object and makes it
available for management. For a Configuration object the MBean would have
actions and attributes like:
Configuration:
--------------
<repository
class="org.apache.avalon.cornerstone.blocks.masterstore.File_Persistent_Obje
ct_Repository">
<protocols>
<protocol>file</protocol>
</protocols>
<types>
<type>OBJECT</type>
</types>
<models>
<model>SYNCHRONOUS</model>
<model>ASYNCHRONOUS</model>
<model>CACHE</model>
</models>
</repository>
---------------
*MBean ---------
Avalon:block=objectstorage,entry=repositories,entry=repository
*attributes ----
Class =
"org.apache.avalon.cornerstone.blocks.masterstore.File_Persistent_Object_Rep
ository"
Value = ""
Children
Avalon:block=objectstorage,entry=repositories,entry=repository,entry=protoco
ls
Avalon:block=objectstorage,entry=repositories,entry=repository,entry=types
Avalon:block=objectstorage,entry=repositories,entry=repository,entry=models
*actions -------
addChild ($name)
removeChild ($name)
setAttribute ($name, $value)
---------------
This solution is very verbose and pretty difficult to use but allows maximum
of flexibility. Also, forces you to put your values in the attributes in
order to facilitate the management.
2) Second solution would be to use XPath to manage (set/get/add/remove) your
configuration. This is prone to errors and its difficult to use from an
administrator perspective.
I prefer the first solution but I'm not convinced that it's the best
approach.
Any thoughts are very welcomed!
Mircea
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Configuration management
Posted by Mircea Toma <mi...@calgary.qcdata.com>.
Hi,
----- Original Message -----
From: "Peter Donald" <do...@apache.org>
To: "Avalon Development" <av...@jakarta.apache.org>
Sent: Tuesday, September 11, 2001 10:18 PM
Subject: Re: Configuration management
> On Wed, 12 Sep 2001 09:02, Mircea Toma wrote:
> > Hi,
> >
> > To change the Configuration at runtime we need a ModifiableConfiguration
(I
> > know that there were some discussions about this) in this way I can have
> > the management written against a interface not a class. I guess the
> > interface is straight forward since this functionality is implemented by
> > the
> > DefaultConfiguration:
>
> Sounds good to me.
>
> > The next issue on *the list* is that I'm not sure how should I implement
> > the configuration management, until now I have two solutions:
> >
> > 1) Have a Dynamic that wraps each Configuration object and makes it
> > available for management. For a Configuration object the MBean would
have
> > actions and attributes like:
> >
> > Configuration:
> > --------------
> > <repository
> >
class="org.apache.avalon.cornerstone.blocks.masterstore.File_Persistent_Obj
> >e ct_Repository">
> > <protocols>
> > <protocol>file</protocol>
> > </protocols>
> > <types>
> > <type>OBJECT</type>
> > </types>
> > <models>
> > <model>SYNCHRONOUS</model>
> > <model>ASYNCHRONOUS</model>
> > <model>CACHE</model>
> > </models>
> > </repository>
> > ---------------
> >
> > *MBean ---------
> > Avalon:block=objectstorage,entry=repositories,entry=repository
> >
> > *attributes ----
> >
> > Class =
> >
"org.apache.avalon.cornerstone.blocks.masterstore.File_Persistent_Object_Re
> >p ository"
> > Value = ""
> >
> > Children
> >
> >
Avalon:block=objectstorage,entry=repositories,entry=repository,entry=protoc
> >o ls
> >
Avalon:block=objectstorage,entry=repositories,entry=repository,entry=types
> >
> >
Avalon:block=objectstorage,entry=repositories,entry=repository,entry=models
> >
> > *actions -------
> >
> > addChild ($name)
> > removeChild ($name)
> > setAttribute ($name, $value)
> > ---------------
> >
> > This solution is very verbose and pretty difficult to use but allows
> > maximum of flexibility. Also, forces you to put your values in the
> > attributes in order to facilitate the management.
> >
> > 2) Second solution would be to use XPath to manage (set/get/add/remove)
> > your configuration. This is prone to errors and its difficult to use
from
> > an administrator perspective.
> >
> >
> > I prefer the first solution but I'm not convinced that it's the best
> > approach.
> > Any thoughts are very welcomed!
>
> I am not sure - neither sounds ideal IMHO. I think it would be best to
> experiment and see what works and what doesn't. The question that is most
> difficult would be how to manage configuration items that have the same
name
> - ie
>
> <model>SYNCHRONOUS</model>
> <model>ASYNCHRONOUS</model>
> <model>CACHE</model>
>
> Because JMX only does flat management. The second approach could handle it
> but the first one has a little difficulty I think.
>
> Ideally I would like the configuration for each block to be defined using
> XSchema. The schema would be defined inside the BlockInfo (.xinfo) file
and
> the management scheme would take this combined with instance data to
> configure it.
>
> So in the BlockInfo file you would have something like
>
> <complexType name="repository">
> <attribute name="class" type="xsd:string"/>
> <element name="protocols"/>
> <element name="types"/>
> <element name="models"/>
> </complexType>
>
> <complexType name="protocols">
> <element name="protocol" minOccurs="1"
> maxOccurs="unbounded" type="xsd:string" />
> </element>
> </complexType>
>
> <complexType name="types">
> <element name="type" minOccurs="1"
> maxOccurs="unbounded" type="xsd:string" />
> </element>
> </complexType>
>
> <complexType name="models">
> <element name="model" minOccurs="1"
> maxOccurs="unbounded" type="xsd:string" />
> </element>
> </complexType>
>
> and you would use that to build the real configuration data. However doing
> that requires a massive amount of work and you would probably want to
> integrate with one of the existing opensource XML editors (merlot comes to
> mind).
Or Castor?! They have (exolab.org) a schema to java class compiler, class
that will do the validation. The problem is you need access to a compiler at
runtime which I think is not the best choice!
>
> I guess that may be the eventual goal but for now it is probably best to
just
> get something up and running and worry about all these details after there
is
> a prototype in which we can test different ideas.
Ok, I get the idea!
Mircea
>
> --
> Cheers,
>
> Pete
>
> ------------------------------------------------
> "No. Try not. Do. Or do not. There is no try."
> -- Yoda
> ------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Configuration management
Posted by Mircea Toma <mi...@calgary.qcdata.com>.
----- Original Message -----
From: "Berin Loritsch" <bl...@apache.org>
To: "Avalon Development" <av...@jakarta.apache.org>
Sent: Wednesday, September 12, 2001 10:59 AM
Subject: Re: Configuration management
> Mircea Toma wrote:
> >
> > Hi,
> >
> > ----- Original Message -----
> > From: "Berin Loritsch" <bl...@apache.org>
> > To: "Avalon Development" <av...@jakarta.apache.org>
> > Sent: Wednesday, September 12, 2001 6:56 AM
> > Subject: Re: Configuration management
> >
> > > Peter Donald wrote:
> > > >
> > > > On Wed, 12 Sep 2001 09:02, Mircea Toma wrote:
> > > > > Hi,
> > > > >
> > > > > To change the Configuration at runtime we need a
> > ModifiableConfiguration (I
> > > > > know that there were some discussions about this) in this way I
can
> > have
> > > > > the management written against a interface not a class. I guess
the
> > > > > interface is straight forward since this functionality is
implemented
> > by
> > > > > the
> > > > > DefaultConfiguration:
> > > >
> > > > Sounds good to me.
> > >
> > > I'm still not crazy about it. There have to be some tight controls
over
> > who
> > > can write to it. The best I can come up with is equivalent to the
> > java.util.Collections
> > > class that returns an unmodifiable collection. To that end, we need a
> > Configuration
> > > that encapsulates other Configuration objects and enforces the
read-only
> > approach.
> > >
> > > The UnmodifiableConfiguration will have a constructor that accepts a
> > Configuration
> > > object. That object and all child objects will be protected from
being >
> > modified.
> >
> > How about having that constructor for the DefaultConfiguration?
>
> It is possible. The UnmodifiableConfiguration approach does not provide
any
> methods whatsoever for altering the contents of the Configuration object,
> which IMO is better.
>
> Remember that there are two Configurable interfaces. The default
Configurable
> which marks components that are configured once and the Reconfigurable
interface
> that marks components that can be configured multiple times. I am not
sure how
> you plan on having the configurations change.
>
> Is it part of the normal opperations for some components to alter their
own
> configuration?
No, not at all!
> Or are you planning on having an outside entity alter the configuration
> file and have the server detect the changes?
>
> If the latter is the case, Excalibur's resource monitoring code is for
you. It will
> notify you when the configuration file has been altered, so you can
reconfigure
> all your components.
This is taken from one of my previous email on this subject:
"The "configuration" management can be done by
changing the configuration trees stored in the ConfigurationRepository, the
Block-s that
will implement Reconfigurable interface will receive automatically the new
configuration (assuming that the "monitor" package will be used)."
Mircea
>
> If the former is the case, this is akin to machine language programs that
alter their
> own code to squeeze out a few more bytes. It just opens up so many
issues.
>
> > > I agree. We should use Schema to describe the XML as much as
possible.
> > Please
> > > note, that I have started to write a Class that will serialize a
> > Configuration
> > > object over a stream.
> >
> > Cool, I guess this is the complement of SAXConfigurationHandler?!
>
> More a compliment to the DefaultConfigurationBuilder, but effectively yes.
> This way, your configuration objects can be persisted no matter where you
> want them to persist. And they should be able to read what they wrote.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Configuration management
Posted by Berin Loritsch <bl...@apache.org>.
Mircea Toma wrote:
>
> Hi,
>
> ----- Original Message -----
> From: "Berin Loritsch" <bl...@apache.org>
> To: "Avalon Development" <av...@jakarta.apache.org>
> Sent: Wednesday, September 12, 2001 6:56 AM
> Subject: Re: Configuration management
>
> > Peter Donald wrote:
> > >
> > > On Wed, 12 Sep 2001 09:02, Mircea Toma wrote:
> > > > Hi,
> > > >
> > > > To change the Configuration at runtime we need a
> ModifiableConfiguration (I
> > > > know that there were some discussions about this) in this way I can
> have
> > > > the management written against a interface not a class. I guess the
> > > > interface is straight forward since this functionality is implemented
> by
> > > > the
> > > > DefaultConfiguration:
> > >
> > > Sounds good to me.
> >
> > I'm still not crazy about it. There have to be some tight controls over
> who
> > can write to it. The best I can come up with is equivalent to the
> java.util.Collections
> > class that returns an unmodifiable collection. To that end, we need a
> Configuration
> > that encapsulates other Configuration objects and enforces the read-only
> approach.
> >
> > The UnmodifiableConfiguration will have a constructor that accepts a
> Configuration
> > object. That object and all child objects will be protected from being >
> modified.
>
> How about having that constructor for the DefaultConfiguration?
It is possible. The UnmodifiableConfiguration approach does not provide any
methods whatsoever for altering the contents of the Configuration object,
which IMO is better.
Remember that there are two Configurable interfaces. The default Configurable
which marks components that are configured once and the Reconfigurable interface
that marks components that can be configured multiple times. I am not sure how
you plan on having the configurations change.
Is it part of the normal opperations for some components to alter their own
configuration? Or are you planning on having an outside entity alter the configuration
file and have the server detect the changes?
If the latter is the case, Excalibur's resource monitoring code is for you. It will
notify you when the configuration file has been altered, so you can reconfigure
all your components.
If the former is the case, this is akin to machine language programs that alter their
own code to squeeze out a few more bytes. It just opens up so many issues.
> > I agree. We should use Schema to describe the XML as much as possible.
> Please
> > note, that I have started to write a Class that will serialize a
> Configuration
> > object over a stream.
>
> Cool, I guess this is the complement of SAXConfigurationHandler?!
More a compliment to the DefaultConfigurationBuilder, but effectively yes.
This way, your configuration objects can be persisted no matter where you
want them to persist. And they should be able to read what they wrote.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Configuration management
Posted by Mircea Toma <mi...@calgary.qcdata.com>.
Hi,
----- Original Message -----
From: "Berin Loritsch" <bl...@apache.org>
To: "Avalon Development" <av...@jakarta.apache.org>
Sent: Wednesday, September 12, 2001 6:56 AM
Subject: Re: Configuration management
> Peter Donald wrote:
> >
> > On Wed, 12 Sep 2001 09:02, Mircea Toma wrote:
> > > Hi,
> > >
> > > To change the Configuration at runtime we need a
ModifiableConfiguration (I
> > > know that there were some discussions about this) in this way I can
have
> > > the management written against a interface not a class. I guess the
> > > interface is straight forward since this functionality is implemented
by
> > > the
> > > DefaultConfiguration:
> >
> > Sounds good to me.
>
> I'm still not crazy about it. There have to be some tight controls over
who
> can write to it. The best I can come up with is equivalent to the
java.util.Collections
> class that returns an unmodifiable collection. To that end, we need a
Configuration
> that encapsulates other Configuration objects and enforces the read-only
approach.
>
> The UnmodifiableConfiguration will have a constructor that accepts a
Configuration
> object. That object and all child objects will be protected from being >
modified.
How about having that constructor for the DefaultConfiguration?
>
> This allows a parent Component to retain the original modifiable
Configuration
> object--but enforces the contract of an unmodifiable Configuration object
being
> passed to Configurable components.
>
>
> > I am not sure - neither sounds ideal IMHO. I think it would be best to
> > experiment and see what works and what doesn't. The question that is
most
> > difficult would be how to manage configuration items that have the same
name
> > - ie
> >
> > <model>SYNCHRONOUS</model>
> > <model>ASYNCHRONOUS</model>
> > <model>CACHE</model>
> >
> > Because JMX only does flat management. The second approach could handle
it
> > but the first one has a little difficulty I think.
> >
> > Ideally I would like the configuration for each block to be defined
using
> > XSchema. The schema would be defined inside the BlockInfo (.xinfo) file
and
> > the management scheme would take this combined with instance data to
> > configure it.
>
> I agree. We should use Schema to describe the XML as much as possible.
Please
> note, that I have started to write a Class that will serialize a
Configuration
> object over a stream.
Cool, I guess this is the complement of SAXConfigurationHandler?!
Mircea
>
> > I guess that may be the eventual goal but for now it is probably best to
just
> > get something up and running and worry about all these details after
there is
> > a prototype in which we can test different ideas.
>
> The idea is to be forward thinking enough to work toward a goal, but
realistic
> enough to get something working (hopefully that can be used toward the end
goal).
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: Configuration management
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: den 12 september 2001 14:57
> To: Avalon Development
> Subject: Re: Configuration management
>
>
> Peter Donald wrote:
> >
> > On Wed, 12 Sep 2001 09:02, Mircea Toma wrote:
> > > Hi,
> > >
> > > To change the Configuration at runtime we need a
> ModifiableConfiguration (I
> > > know that there were some discussions about this) in this way
> I can have
> > > the management written against a interface not a class. I guess the
> > > interface is straight forward since this functionality is
> implemented by
> > > the
> > > DefaultConfiguration:
> >
> > Sounds good to me.
I am against it. I think it is more about when it can be written to than who
does the writing. The ComponentManager should deal with this by
re-initializing components with static, read-only configurations when they
are returned. So for the three types of components:
Recyclable:
Instead of recycling, see if the component is reconfigurable and
reconfigure it. Otherwise, dispose and re-initialize.
Threadsafe:
Wait until all references are released, re-initialize.
Single-threaded:
Switch.
Otherwise we will have race conditions all over the place.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Configuration management
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
>
> On Wed, 12 Sep 2001 09:02, Mircea Toma wrote:
> > Hi,
> >
> > To change the Configuration at runtime we need a ModifiableConfiguration (I
> > know that there were some discussions about this) in this way I can have
> > the management written against a interface not a class. I guess the
> > interface is straight forward since this functionality is implemented by
> > the
> > DefaultConfiguration:
>
> Sounds good to me.
I'm still not crazy about it. There have to be some tight controls over who
can write to it. The best I can come up with is equivalent to the java.util.Collections
class that returns an unmodifiable collection. To that end, we need a Configuration
that encapsulates other Configuration objects and enforces the read-only approach.
The UnmodifiableConfiguration will have a constructor that accepts a Configuration
object. That object and all child objects will be protected from being modified.
This allows a parent Component to retain the original modifiable Configuration
object--but enforces the contract of an unmodifiable Configuration object being
passed to Configurable components.
> I am not sure - neither sounds ideal IMHO. I think it would be best to
> experiment and see what works and what doesn't. The question that is most
> difficult would be how to manage configuration items that have the same name
> - ie
>
> <model>SYNCHRONOUS</model>
> <model>ASYNCHRONOUS</model>
> <model>CACHE</model>
>
> Because JMX only does flat management. The second approach could handle it
> but the first one has a little difficulty I think.
>
> Ideally I would like the configuration for each block to be defined using
> XSchema. The schema would be defined inside the BlockInfo (.xinfo) file and
> the management scheme would take this combined with instance data to
> configure it.
I agree. We should use Schema to describe the XML as much as possible. Please
note, that I have started to write a Class that will serialize a Configuration
object over a stream.
> I guess that may be the eventual goal but for now it is probably best to just
> get something up and running and worry about all these details after there is
> a prototype in which we can test different ideas.
The idea is to be forward thinking enough to work toward a goal, but realistic
enough to get something working (hopefully that can be used toward the end goal).
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Configuration management
Posted by Peter Donald <do...@apache.org>.
On Wed, 12 Sep 2001 09:02, Mircea Toma wrote:
> Hi,
>
> To change the Configuration at runtime we need a ModifiableConfiguration (I
> know that there were some discussions about this) in this way I can have
> the management written against a interface not a class. I guess the
> interface is straight forward since this functionality is implemented by
> the
> DefaultConfiguration:
Sounds good to me.
> The next issue on *the list* is that I'm not sure how should I implement
> the configuration management, until now I have two solutions:
>
> 1) Have a Dynamic that wraps each Configuration object and makes it
> available for management. For a Configuration object the MBean would have
> actions and attributes like:
>
> Configuration:
> --------------
> <repository
> class="org.apache.avalon.cornerstone.blocks.masterstore.File_Persistent_Obj
>e ct_Repository">
> <protocols>
> <protocol>file</protocol>
> </protocols>
> <types>
> <type>OBJECT</type>
> </types>
> <models>
> <model>SYNCHRONOUS</model>
> <model>ASYNCHRONOUS</model>
> <model>CACHE</model>
> </models>
> </repository>
> ---------------
>
> *MBean ---------
> Avalon:block=objectstorage,entry=repositories,entry=repository
>
> *attributes ----
>
> Class =
> "org.apache.avalon.cornerstone.blocks.masterstore.File_Persistent_Object_Re
>p ository"
> Value = ""
>
> Children
>
> Avalon:block=objectstorage,entry=repositories,entry=repository,entry=protoc
>o ls
> Avalon:block=objectstorage,entry=repositories,entry=repository,entry=types
>
> Avalon:block=objectstorage,entry=repositories,entry=repository,entry=models
>
> *actions -------
>
> addChild ($name)
> removeChild ($name)
> setAttribute ($name, $value)
> ---------------
>
> This solution is very verbose and pretty difficult to use but allows
> maximum of flexibility. Also, forces you to put your values in the
> attributes in order to facilitate the management.
>
> 2) Second solution would be to use XPath to manage (set/get/add/remove)
> your configuration. This is prone to errors and its difficult to use from
> an administrator perspective.
>
>
> I prefer the first solution but I'm not convinced that it's the best
> approach.
> Any thoughts are very welcomed!
I am not sure - neither sounds ideal IMHO. I think it would be best to
experiment and see what works and what doesn't. The question that is most
difficult would be how to manage configuration items that have the same name
- ie
<model>SYNCHRONOUS</model>
<model>ASYNCHRONOUS</model>
<model>CACHE</model>
Because JMX only does flat management. The second approach could handle it
but the first one has a little difficulty I think.
Ideally I would like the configuration for each block to be defined using
XSchema. The schema would be defined inside the BlockInfo (.xinfo) file and
the management scheme would take this combined with instance data to
configure it.
So in the BlockInfo file you would have something like
<complexType name="repository">
<attribute name="class" type="xsd:string"/>
<element name="protocols"/>
<element name="types"/>
<element name="models"/>
</complexType>
<complexType name="protocols">
<element name="protocol" minOccurs="1"
maxOccurs="unbounded" type="xsd:string" />
</element>
</complexType>
<complexType name="types">
<element name="type" minOccurs="1"
maxOccurs="unbounded" type="xsd:string" />
</element>
</complexType>
<complexType name="models">
<element name="model" minOccurs="1"
maxOccurs="unbounded" type="xsd:string" />
</element>
</complexType>
and you would use that to build the real configuration data. However doing
that requires a massive amount of work and you would probably want to
integrate with one of the existing opensource XML editors (merlot comes to
mind).
I guess that may be the eventual goal but for now it is probably best to just
get something up and running and worry about all these details after there is
a prototype in which we can test different ideas.
--
Cheers,
Pete
------------------------------------------------
"No. Try not. Do. Or do not. There is no try."
-- Yoda
------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org