> De: Berin Loritsch [mailto:[EMAIL PROTECTED]
> In the general case, yes. However, let's not completely > preclude the possibility of a PicoContainer type of > initialization (either all in the constructor, or throught setter/getters). Ow! Now I see a nice and different approach. > It doesn't have to be on demand. You can do it all at one time. > You will find that the shutdown order is *very* important. Forgot to think about that... :-\ > All components should have their own "LookupManager" so that they > only see what they need to see. Fortress is somewhat crippled in that respect. Uh.. That far different from what I was thinking. So the dependency information suddently appear to me as a must have... > "real" instances--a proxied instance provides additional security, and > a natural location to add interceptors (i.e. functions that get called > before and after the interface method's call). Yeah. Its nice to have some AOP kind of functionality. Unfortunately transparent proxies in .Net is only available to classes that derive from MarshalByRef. I think it's very intrusive to force one to derive from MarshalByRef and lost his only oportunity to implementation inheritante (I know there is work arounds, anyway it's ugly) > "praying" for disposal--as much as possible we want to avoid "prayer" > as a design constraint. Don't get me wrong, I am a regular practicer > of prayer, but it has its place. ;P The container is responsible for > properly disposing of components when they are no longer needed. Sure. I was kidding. What's frightening me is instanciate the dependencies and pass on their ownership to the component. Then we lost control. If the component implementation doesn't dispose his dependencies properly, we're lost. To ilustrate my fears, imagine that: - Component A depends on Component B - Container realize that it needs to instantiate A, before it instantiante the component B (lifestyle Pooled) and initialize it's lifecycle - Container instantiate A and pass on component B In order to make component B available to pooling, his factory needs a message telling the use of component B instance is over. Who call this message? Should be the container. How the container knows component A terminates its use of dependencies? Ok, it will know when it dispose component A... Is that the idea? > I am definitely willing to help you through the hurdles. So that I can > help bridge the gap, where are you in your understanding of how > containers work? I appreciate that. I thought I knew how a container works by my experience using Fortress.. I was wrong :-) As a simple point a view a Container should handle different lifestyles exposed by components and offers a few common set of services as configuration and logging. The entry point for a Avalon based application is the ServiceManager implementation, as it enable look ups by roles. After a sucessfull lookup the container should instantiate the implementation and deals with the lifecycle. Then we enter in the implementation arena. My understanding of Fortress show me that there is a ComponentHandler that holds a ComponentFactory. Exception for ComponentFactory that seems to implement both concerns. :-) After using a component/service, a correct client implementation should return the instance to ServiceManager, that should return it to ComponentHandler. What I've missed? hammett --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
