-------- Original Message -------- Subject: Re: Dynamic Reconfiguration Date: Sun, 29 Jun 2003 16:35:15 +0200 From: Stephen McConnell <[EMAIL PROTECTED]> Reply-To: Avalon Developers List <[EMAIL PROTECTED]> To: Avalon Developers List <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED] References: <[EMAIL PROTECTED]>
Noel:
While the subject of this message is about re-configuration, I think that there is an argument for looking at the requirements in-terms of re-deployment.
|---------- deployment --------------------->| | | | |<----- suspension ---| | | | |<-- decommissioning --| | |---- resumption ---->| | | | | |<-------------decommissioning --------------|
In the above diagram, "deployment" covers the instantiation and lifecycle processing of a component by a container. The act of "suspension" is to place the component in a volatile state during which the state provided to it by the container during the prior deployment cycle is subject to change. An act of "resumption" is the process of taking a component from a volatile state to a stable deployed state, and finally, the act of "decommissioning" covers the shutdown stages leading to component disposal.
In this picture the open question is the semantic applicable during a "resumption" phase. It is reasonable to assume that context entries are immutable? It is possible that we may want to change the temporary working directory used by the component? Perhaps we want to apply a logging channel that has been reconfigured to use a different output target or priority? Perhaps we want to swap the source provider component for a DNS service with another provider? Maybe some parameters need to be propagated to the component, or potentially some configuration information needs to be reassessed. All of these question concern state that is supplied by a container to a component - and all represent reasonable candidates for "re-assessment".
One of the things that can be done to make the above scenario more manageable is to mark state that is supplied to a component by a container as immutable. For example, it is possible to imagine a component type declaring (as part of its meta-info) the immutable versus modifiable information. This could be done at the level of individual context entries, individual parameter values, even nodes of a configuration hierarchy. Based on this information, a container could assess the scope of re-deployment that a particular component implementation supports and handle the resumption cycle accordingly.
In practice, the process of resumption could be viewed as re-application of the lifecycle stages, qualified relative to the immutable state of the respective artifacts (e.g. if logging is declared as immutable by a component implementation, then it makes no sense for a container to allow or attempt to apply a change). In fact, this constraint could be pushed back to the management access point such that the initiation of change potential within a client interface could be qualified by the component meta info.
My 0.02 euro on a Sunday afternoon.
Cheers, Steve.
Noel J. Bergman wrote:
Avalon frameworks manage the core tasks and should ideally manage the reconfiguration of those tasks. Achieving this means that all Avalon components benefit from these advances.
Ideally, yes. This is something that we should bring up with Avalon, not just here. They should provide the core facilities, and we should know how to use them.
it.The configuration file, config.xml, is essentially a persistent store for the configuration parameters. As it is XML based we may as well go with
We may well want to expose the parsed parameters as Java objects through some kind of interface.
You mean, other than the existing ones?
Probably James would use the Java objects as its configuration source and perist any changes to the Java objects by updating config.xml.
Avalon provides the configuration interfaces, and should be responsible for the core support. However, I would not want to see normal components able to effect configuratin changes. The JMX support should be able to do so.
Basically, I agree with your thoughts. I am simply emphasizing that the core integration of (re-)configuration and JMX should be part of Avalon. If we do it here, for example if that is something you want to undertake, it really should be done by contributing to Avalon.
--- Noel
cc: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
Sent via James running under Merlin as an NT service. http://avalon.apache.org/sandbox/merlin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
Sent via James running under Merlin as an NT service. http://avalon.apache.org/sandbox/merlin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
