-------- 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]>
Steve, > 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. As Avalon already defines these phases - http://avalon.apache.org/framework/reference-the-lifecycle.html - this seems an entirely sensible approach. It is important that we have control over the order that components are suspended and resumed. For instance, we would want to stop injecting mail into the mailet chain and have the mailet chain complete the processing of currently injected mail prior to suspending. The reverse during resumption. I don't see anything in Avalon that enables such dependencies to be defined, but I'm no expert. > In this picture the open question is the semantic applicable during a > "resumption" phase. It is reasonable to assume that context > entries are immutable? Yes. For components that do not support the suspend/resume this would be the default. For components that do support suspend/resume I think that this should also be the default. Supporting suspend/resume is saying the component can be suspended and resumed. Declaring context entries as mutable is saying that the component supports changing them when in the suspended state. Is it a requirement that all components in the server must support suspend/resume in order for the server instance to support it? If not, what we could end up with non-suspended components trying to talk suspended ones. Not good! Maybe we have to add a default implementation of suspend/resume for all components, where suspend invokes destroy() and resume invokes init(). Unfortunatley, there is a high chance of components that (incorrectly) do not cleanly release resources in destroy() which were acquired during init() failing. > 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. Add this information to .xinfo? It can then be held in the component code as JavaDoc and generated with XDoclet. > My 0.02 euro on a Sunday afternoon. And very good value too. -- Steve --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
