> From: Stephen McConnell [mailto:[EMAIL PROTECTED]] > > Berin Loritsch wrote: > > >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. > > > > I agree with the defintion - the seperation I'm referring to is more > implementation level. In Merlin the DefaultContainer implementation > handles assembly, startup and shutdown. The > ProfileDesignator (created > by the container during assembly) is an implementation of > ResourceDesignator that handles the configuration, context, > servicing, > initialization - i.e. all of the lifecycle stuff. From the > outside - the > Container is responsible for all - however, when we cet into the > implementation archtecture of the container itself, and if we > break out > assembly, your left with the ResourceDesignator implementations, the > DefaultProvider (which works hand-in-hand with the > container), and the > LifecycleHelper as the primary classes.
Ok. It's confusing when you have a container that is composed of many parts, one of which happens to also be called a container. > My assumption is that this is not a concern for the client - its a > concern related to an implementation of ResourceDescriptor. > Presumably > access and release events flow from a client components > interaction with > its component/service manager - the manager interacts with > the resource > and the resource implementation would handle any recyling. > > Am I on the right track here ? Access/Release events are related to how the container manages that portion of the component's lifecycle. It has nothing to do with the client. > I've been digging through the lfecyle extension stuff. There > is no class level association between a lifecycle interface > and its manager which means that reflection will not solve > the problem. Not as of yet. As I mentioned in another email, reflection also has several issues regarding the addition of more than one extension class. > The container cannot check the interfaces supported by a the > component class for an extension interface (because > Exploitable does not extends a base interface). What is > needed at the type (meta-info) level is a declaration of the > manager class. True. However, what happens if there are multiple extension handlers that can work with the interface? If the LifecycelExtensionHandler class were to expose the interfaces that it handles, we can use reflection--as long as we can resolve the first problem from my above response. > A type implementing Exploitable introduces obligations towards it > container at two level - (a) that fact that it needs to be > handled by an > extension manager (e.g. LifecycleHelper), and (b) that it has context > dependecies (i.e. the container has to populate the context > entries with > values. Both of these characteristics are meta-info level stuff. > > At the type (meta-info) level we would be looking at something like: > > <component-info> > <component> > <name="my-exploitable-component"/> > </component> > <extensions> > <!-- order list of extensions --> > <extension class="ExploitationManager" name="exploitable"> > <context> > <!-- context constraints here --> > </context> > </extensions> > </extensions> > </component-info> That would probably work. The important thing is that we provide a means of *validating* if we can use the component in our system. As long as we don't force one LifecycleHelper implementation, we can do this much. > > Remember that the information is developer defined and cannot be > modified by a configuration. Absolutely. > Next is the Profile (meta-data) where we are concerned with > customization of the instantiation criteria. In the case of an > extension, we are concerned with declaring the context > information to be > supplied to the context instance used in lifecycle handling > implied by > the extension. Wouldn't we want to just merge all the context requirements into one section. It would be easier to deal with than having to modify it in several locations. > >I really haven't found a need beyond these four basic types of > >lifestyles. Have you run across something that I haven't? > > > > Before answering that I want to dig a little bit more. > In Fortress there are the handler dealing with the following > lifestyles: > > singleton - (always returns the same instance) > factory - (creates a new instance) > thread - (provides new instance keyed by thread) > pooled - (returns recyclable instances per request) > > All of the above are constraints supplied by a developer > relative to the > type of component. As such, this is meta-info and should > appear via the > Type class. At the Profile level there is information > concerning things > like pool size - etc. (i.e. the deployment criteria). At the > type level > I'm currently thinking about how lifestyle could be represented using > component type attributes. I'm assuming the following would > be sufficient: > > <component-info> > <component> > <attributes> > <attribute key="avalon:lifestyle" value="pooled"/> > <attributes> > </attributes> > </component-info> > > Where the "avalon:lifestyle" attribute value could be one of pooled, > thread, singleton or factory. Would these be attributes that are consistent with all containers? If so, I would prefer something along the lines of: <component-info lifestyle="pooled"/> It is a core concern of how the container deals with the component, and it is *far* less verbose. The more verbose attributes section should IMO be reserved for additional component guarantees like persistent vs. transient storage. > In a component profile we need to be able to provide > lifestyle parameters: > > <component class="MyExploitableComponent"> > > <!-- declaration of context entries to be supplied a handler --> > > <lifestyle class="MyPoolManagerImpl"> > <entry key="initial" class="int">14</entry> > <entry key="maximum" class="int">100</entry> > </lifestyle> > > </component> Hmm. Currently, this is handled by attributes on the config.xml: <my-pooled-component pool-max="100" pool-min="14" pool-grow="4"/> Those attributes allow the person who is responsible for *tuning* the application quick access to the necessary information. I am not sure how the "MyPoolManagerImpl" is expected to behave. MPool has its own Command that operates every so often that sets the pool size. Eventually I want to give that Command some real brains so that it can pre-allocate instances before the expected load, and de-allocate instances during times of expected quiet. The bottom line is that I want MPool to get to the point where it tunes itself, and the whole constraint of initial and maximum number of instances is no longer necessary. > During validation, the container would have to check that the > component > lifestyle attribute in the meta-info model is consitent with > the class > supplied in the meta-data model. In addition, for a clean > defintion of > this at meta-info and meta-data levels, we would need to get somewhat > more rigorouse about the lifestyle meta-data context entries > than what I > have described above (but you get the idea). Ok. > >:) Yep, you got it! > > > > > > Do I get a prize? > ;-) Sorry, we ran out :( -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
