avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hamilton VerĂ­ssimo de Oliveira <holive...@bvtibusiness.com.br>
Subject Re: Container Extensions
Date Fri, 12 Sep 2003 19:47:18 GMT
> De: Berin Loritsch [mailto:bloritsch@apache.org] 

> 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

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

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
>    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
  - 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
> 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

What I've missed? 


To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message