Steve Brewin wrote:
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.
Going from the specification we have:
Recontextualize Recomposable/Reserviceable Reparameterizable Reconfigurable
These interface do two things:
a) act as marker interfaces that signal to a container
that a component can handle lifecycle reprocessing b) provides the operation through which a component
receives artifacts from the containerGenerally speaking, Avalon is trying to move away from marker interfaces as they tend to tie implementation semantics into the interface. A better approach is to declare the mutable nature of an supplied artifact inside meta info (but this is more an A5 subject).
It is important that we have control over the order that components are
suspended and resumed.
Umm, there is a very important question here - who is "we"? A container is going "control" the sequencing of component suspension and resumption. In the James case this is interesting because below the macro level Avalon components (handled by an Avalon container), you have multiple mailet instances. The "James" component in this context is acting as a container of these instances, and as such, the James component has rather a lot of work to do during a suspension re-deployment cycle (equivalent to a classic Avalon container but focussed on the mailet implementation classes and instances).
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.
The Mailet API defines the services that a mailet instance provides. The James component is responsible for deployment and decommissioning of mailet implementation scenarios (mailet class + config + context, etc). If there is a formal component model for a mailet implementation, then James can do equivalent management of mailets using an embedded container. Avalon project content in this area is emerging - in particular the area of composite containment is rather active.
What are the principals/ideas used inside James for things like mailet deployment? Are mailets implementations potentially suspedable/resumable?
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!
If component A is suspended, and component B is dependent on A but B is not suspendable, the container has to decommission B (i.e. take the component instance B out of existence - which includes decommissioning of all components are dependent on or part of B). This is not totally hard-and-fast because different containers can use different tricks via proxies to fake a suspension. I.e. if B were allowed to continue and if it made an invocation against A, the invocation could be intercepted and stalled within a proxy pending the resumption of A.
Maybe we have to add a default implementation of suspend/resume for all components, where suspend invokes destroy() and resume invokes init().
This should be a container concern - nothing needed on the component. There a lots of things a container can do that don't require any additions on a component (although I admit that non of this is not terribly simple as far as container implementation overhead is concerned).
Unfortunatley, there is a high chance of components that (incorrectly) do
not cleanly release resources in destroy() which were acquired during init()
failing.
This is another area where container implementations can do things for you. If a component deployment fails - the container can unwind things such that it really does not matter what the component thinks it has references to. For example, the component thinks it has a reference to another component when in fact all it has is a reference to a proxy, and the container can take care of proxy disposal independently of the component.
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.
Yep.
My 0.02 euro on a Sunday afternoon.
And very good value too.
Must be all of the sunshine!
Cheers, Steve.
-- Steve
--------------------------------------------------------------------- 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]
