> From: Stephen McConnell [mailto:[EMAIL PROTECTED]] > > Berin Loritsch wrote: > > > There is conceptual difference here about the role of the > container in > Merlin and Fortress (I think). In Merlin the container handles the > assembly of the components resulting in the establishment of a set of > ResourceDesignator instances. ResourceDesignators are supplied to a > Component/ServiceManager in map, keyed by role name. When a client > invokes lookup the manager implementation invokes > getInstance() on the > ResourceDesignator - in the case of threadsafe component - if the > instance has not been established, it uses a lifecycle > helper, provider > and meta-data reference to build the instance (including the > supply of a > compoent/service manager packaged with dependent > ResorurceDesignators).
In my mind, the container is very broad. It is the set of code that manages the components--their loading policies, configuration, mapping, everything. I think you limit the container to something within your concept of Merlin. > In effect, the container has nothing to do after > initialization except > handle the components that have a activation-on-startup > policy, and any > shutdown/disposal requests from its kernel. This appears to be > different in Fortress because the Fortress container plays an active > runtime role (by runtime I mean post start). My current thinking is > that the dynamic aspects of the Fortress Container should be > positioned > within an ResoruceDesignator implemetation. If you take a > look at the > source merlin.container.ProfileDesignator you will see that > it basically > doesn't do much more than delegate requests of to the > lifecycle helper - > the lifecycle helper then uses merlin.container.DefaultProvider to > resolve context, depedecies and so forth, using the meta-data > model as > execution context. My feeling is that we can handle different > "semantic" > appraches through variations on ResourceDesignator implementations. What about access/release based events? In order to satisfy supporting the legacy Recyclable interface, we need to be able to recycle the component. We also need to be able to destroy factory-based components. Fortress does this asyncronously, so the act of releasing a component has no appearent effect on the operation of the system. > > Agreed - I guess this is a question for Markus - can you > eliminate the > necessity for the declaration in the code of the extension to an > extension manager? For example, in the Fortress example for the > extensions - there is a container that is explicity declaring the > extension to the manager. It would be designable for a lifecycle > handler to figure this out for itself based on interfaces > implemented by > looking at the component class? If so, do you see any problems > integrating extension support into the > merlin.container.LifecycleHelper > class? The concept of Extensions as they are currently implemented is based on the fact that we know our container needs to support the new interfaces. The important thing here is that we need to guarantee a consistent ordering of lifecycle events. We cannot do that based on reflection alone. For instance, if we have multiple extensions (which I personally think is a dubious requirement) we have to apply the extensions in the proper order. Extensions are inherently application specific, so setting up the container requires the forknowledge of setting the proper lifecycle interfaces. We need to decide if that is something we want to dynamically coordinate (Merlin style) or explicitly set (Fortress style). > I've been thinking off-and-on about the hadler declaration and the > handler types in Fortress. They tend to reflect lifestyle > concerns but > at the same time they mix functional policy - let me explain - a > component may be pooled and thread-safe - it may be pooled and > non-thread safe. Other aspect such as lazy or immediate > activation are > seperate from the issue of thread-safe - I guess I would like > to see a > breakout of the different *lifestyle* and the different *deployment* > policies. I've tried to break out a table isolating the notions of > singeton, poolable, per-thead, pre-request, and mapping these against > thread-dafe and non-thread-safe components but I havn't arrived at a > clean seperation. Any thoughts on this ? I guess my hidden > agenda here > is to eliminate the requirement for the declaration of the > handler class > in preference to the declaration of lifestyle policy(ies). Hmm. In my mind, I would not waste resources by pooling ThreadSafe components. If they are ThreadSafe, only provide one. By virtue of the fact that components are ThreadSafe they are fully re-entrant, re-usable, and provide a consistent environment no matter how many threads are accessing it simultaneously. I reserve pooling/per-thread lifestyles for components that are re-usable, even though they are not re-entrant or force an order of method invocations. The exact choice depends on if I need a unique instance per request vs. a unique instance per thread. Lastly, the pure factory method is used if a component is not re-useable. A component that is not re-usable is like a hamburger that is not edible IMNSHO. It looks like a hamburger, but it causes more problems than it solves if you try to eat it. Same with this type of component. I really haven't found a need beyond these four basic types of lifestyles. Have you run across something that I haven't? > > Ok - this now makes sence - basically RoleManager is maintaining > meta-data in the form of easily assecible infromation in the form of > configuration framgments and enabling these fragments to be passed > around as needed. Merlin's apprach is to eliminate the configuration > but sucking in the the configuration once, and building a > formal model > accessible using the merlin.model API. :) Yep, you got it! > On the subject of maintainability - the Merlin stuff is > really easy to > use - PROVIDING - the meta-info is documentated in an .xinfo. > It gets > even easier if you use .xprofile which is a static defintion > of a set of > instantiation profiles. I would be really interested to get a better > picture of the service model used by Cocoon assuming formal > dependecies > were declared in advance - which will really help in sorting out the > real needs for dynamic service lookup. Is the "how-to"/example on the site? I want to get a feel for it. As to Cocoon component models, I will help out where I can. I will say that 90% of the time, what changes is the sitemap--the portion which details *which* component implementation/configuration I need to use to process a particular request. It is rare that the components are actually changed. In those events that the component map is changed, it is usually adding new components. However it is feasible and reasonable to assume is that role names (as you define them) will be changed at any time the sitemap is reloaded. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
