avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: Container Extensions
Date Fri, 12 Sep 2003 20:03:31 GMT
Hamilton VerĂ­ssimo de Oliveira wrote:

>>De: Berin Loritsch [mailto:bloritsch@apache.org] 
> 

<snip type="realization of importance for dependencies"/>

> So the dependency information suddently appear to me as a must have...
> 

Yep.  That's what we have found.

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

Yuck.  Anyway, that is a topic for later discussion.  The first step
is to pass the instance by interface.

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

First, the container never relinquishes control or ownership.  It merely
lets components use each other in a managed way.


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

Let's worry more about the simple case first.  The simple case is singletons
(one instance of a component per container).

This is where a proxy can come in handy.  The proxy would be able to have
"garbage collection" policies for a component instance, or do a lookup/
release behind the scenes for each method call.  That would allow you to
only have the instance of the component when it is needed, and still allow
the container to have complete control.

Granted this is a complicated way of doing things, but as always focus on
the simple stuff first.

Right now in Java land, we have a lookup() and release() cycle for components
being looked up.  All that is done with the associated LookupManager (AKA
ServiceManager).  However, you probably have already noticed the absense of
the release() method in the C# code.

The reason is that I wanted to make the system as unobtrusive to the client
(code using a component) as possible.  So for the time being, let's focus on
the simple (singleton) lifestyle.  If we need something else, we can address
it then.



> 
> 
>>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: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
> 
> 
> 


-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


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


Mime
View raw message