----- Original Message ----- From: "Berin Loritsch" <[EMAIL PROTECTED]>
> Are you referring to the lifecycle of the container itself? It's > not clear. It looks as if you are wanting to duplicate the Lifecycle > Extensions which we have in Java. The same fuctionality implemented in a different way. > 1) A container is responsible for the life of a component, and satisfying > any and all dependencies. Sounds simple, but is definitely not :-) Let's go a step further: - in the initialization phase the assemblies are checked and avalon components/services are discovered. Every information a component exposes about itself through Attributes goes to to a ComponentEntry (something like MetaInfo in Fortress) - by now we have the dependencies list/lifestyle/config/logger name for the component - sometime later, someone make a look up for the component that has dependencies. What shall we do at this time? * Simple situation - the dependencies doesnt hold another dependencies * Complex situation - the dependencies hold another dependencies * Evil situation - the dependencies depends each other (A depends on B which depends on A) > The obvious point to start with is the first one. If you can get a component > loaded, and verify that all its dependencies are also loaded, then you have > a workable foundation. Got it. I will deffer the lifecycle extensions idea.. Anyway I tried to solve the relation: - Component has a ComponentHandler which has a ComponentFactory by using a LifestyleManager to centralize invocation of lifestyle methods. > Up until this time it is completely premature to define interfaces and how > they interact. We simply don't have the appropriate information. Agree. hammett --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
