On Thu, 31 Oct 2002 12:12, Olaf Bergner wrote: > 1. Central is the concept of a component. This one is quite clear. It is a > highly reusable programmatic entity with a well-defined lifecycle and a > work interface, performing a non-trivial task. All dependencies that must > be resolved for a component to be able to fulfill its duty must be > satisfied via its lifecycle interfaces.
yep. > 2. The concept of a component is dependent upon that of a container. A > component's container is that piece of code that creates the component and > possibly promotes its availability to other components. yep. > It is NOT, however, > (my first thought) another component using said component after being > composed. yep. > Neither Avalon nor ECM seem to have a programmatic means of clearly > defining what a container is. To them, it's just a concept. This situation > is different with Fortress and Merlin2. cyep. > 3. A central aspect of any application modelled after the concepts promoted > by Avalon is that it constitutes - either implicitly or explicitly - a > unidirected (from parent to child) circle-free graph, in short a tree, of > dependent components, child components being dependent on parent > components, but not vice versa (IOC). While this is conceptually true, it > need not be on the implementation level, since threadsafe components might > be shared by multiple parent components. This is, however, hidden from the > components' view. It is a Directed Acyclic Graph. So the same component can be shared between multiple "trees" but there will never be a path through the graph where the same component appears twice. > 4. While the knowledge of this component tree is only implicit in ECM and - > to a certain degree - in Fortress (any application must have an at least > implicit knowledge of its structure to function correctly), Merlin2 > explicitly defines a meta model for it, thus enabling a user to dynamically > access and manipulate it. Phoenix also has a metadata based model. > These observations, if true, will probably appear trivial to most of you, > but I wanted to get the basics straight before moving on. I just started > porting a small app I once wrote to Avalon, wondering, which container > framework to use. Since it need not be of production quality - it's just > for the fun of it - I currently tend towards Fortress, though I started out > using ECM. Yet I am getting tired of all those deprecation warnings, and > Fortress seems quite easy to understand, whereas Merlin2 is a different > beast altogether (and probably overkill for my purposes). Any different > views? Try Phoenix if you doing a standalone app. > 1. In "Avalon Framework - Guide - COP in Avalon" - "The Component Manager" > : Towards the end, it reads "Sometimes you need to create a new interface > name that does nothing more than allow access to alternate roles who have > the same role." Shouldn't it end with "... who perform the same function" > or " ...who are functionally equivalent."? I changed that chunk to read Some containers require that the interface name match the key used to lookup component. In this situation it you may need to create a new interface that does nothing more than extend another interface and add a new role. It should be pushed to website when we next update. > 2. In "Developing With Apache Avalon" - "Implementing The Dream" - > "Initialization and Disposal Approach" : I struggled a bit with the > paragraph "The main disadvantage of this approach comes into play...", at > times confusing "this object", "component", thinking hard about "... the > component whose reference it has". I Think I got it right, and making the > reader think hard could be considered a virtue in itself ;) > > Otherwise, it is undoubtedly one of the best pieces of > documentation/introduction I have ever read! Keep up the good work. Berin gets to claim the fame for that ;) -- Cheers, Peter Donald He strains to hear a whisper who refuses to hear a shout. -- To unsubscribe, e-mail: <mailto:avalon-users-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-users-help@;jakarta.apache.org>
