Berin Loritsch wrote:
<snip-content-related-to-javax.sql.DataSources/>
In the process, I am looking for what things we can be doing less of, and what we should focus our core strengths in. For example, what is the proper balance between developer ease of use and conceptual purity? What is the balance between separation and fragmentation of concerns? How do we encourage more widespread adoption of Avalon?
Berin: Your question concerning the balance between separation and fragmentation of concerns got my attention. I've been thinking about this as a result of the context discussions and have been quietly thinking about what it is that makes Avalon attractive, what it is that makes Avalon non-attractive, and how all of this plays into the future of Avalon A4/A5/Ax. After playing around with a bunch of diagrams, I came up with an abstract model of what a container does in terms to a component at a rather high level of abstraction - together with a mapping of this abstraction down to the Avalon notion of component lifecycle and container related concerns. potential | | candidate | | | | |--- creation --> | component | | | | |---- deployment ---->| | | | | |<-- decommissioning -| | | |<-- termination -| | The above diagram presents an abstract state machine from a container's point-of-view. Potential components exist as a result of a containment systems discovery process (classpath, meta-info and meta-data scanning, etc.). The creation phase is about the creation of a "candidate" component - involving validation of meta-info and meta-data, assignment of a lifestyle handler, assembly of dependencies, and finally, verification that all logical dependencies are resolvable. Moving from "candidate" to "component" is where we get into the Avalon framework side of things. This involves object instantiation application of a logging channel, contextualization, servicing, initialization, and potential startup. I've referred to this as the deployment phase. What is important to note is that that Avalon has particular idea of what deployment means - but not formal notion of deployment as a phase. If we look into deployment in more detail (still maintaining an abstraction above the Avalon framework model) there are a number of particular stages that we can separate out as distinct and significant. The deployment sub-stages include: * logging strategy * configuration strategy * context strategy * initialization strategy In Avalon the "logging strategy" is based on the LogEnabled interface And the assignment of a logging channel via that interface. What is Important to note is that this is potentially one of may different logging strategies providing we can abstract ourselves above the stage implementation and into the notion of strategy definition. The Avalon configuration strategy is basically the combination of Configurable and Parameterizable. The Avalon context strategy is the combination of the Contextualization and Service stages. An finally, the Avalon initialization strategy is represented by the Initializable interface and methods on the Startable interface or possibly the Executable interface. Something important in the above is the absence of references to things Like recomposable, reconfigurable, etc. Instead, if we look at the Individual artifacts that are supplied by a container to a component, and given that these artifacts are supplied based on information # declare in meta-info, than "re-" aspect can be qualified relative to the artifact being applied. For example, if I declare that the component needs a logging channel, the default declaration could be that the logging channel is final - i.e. tyhe component does not support re-assignment of the logging channel. The same concept can be applied to configuration and context related information - is contextualization final or not - are entries in a context object final or not? Are service under a service manager final or not? Same thinking in terms of entries in a service manager, etc. This allows us to eliminate completely the "re-X" approach and instead - declare this at the level of the meta-info that a component is declaring to its container. Second interesting aspect of the above is the folding of initializable And startable under a single initialization phase. This is possible because there is no longer a particular semantic difference between a initialized and started (because the notion of re-X has been abstracted out). Decommissioning of a component is equivalent to taking a component back to its pre-initialized state where the volatile members are all of the non-final artifacts that a component type has declared. You may be wondering what the benefit of this abstraction is. Basically, the key aspect is focussing on the containment abstraction and considering the state model described above as the containment management problem. It means that a container implementation can handle objects that implement different component models - Avalon, Servlet, etc. Is it feasible? Yes. I've recently introduced an abstraction to context management in The avalon-sandbox/assembly package that enables a component to implement any interface for the contextualization stage. This approach can be applied to an abstract contextualization phase (covering both Avalon contexualization and servicing). The same applies to the abstract notions of logging, configuration and initialization. I think the above is a rational approach to addressing some key issues: (a) simplification for the component author (b) applicability of Avalon to a wider audience Both of the above seem to address the issues your raising. Cheers, Steve. -- mailto:[EMAIL PROTECTED]://www.osm.net Stephen J. McConnell -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
