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 Thu, 11 Sep 2003 21:01:18 GMT
hammett wrote:

> Whichs phases a container should exposes to enable developers 
> to hook up and extend the lifecycle of components?

For now, we haven't really gotten that far.

> 
> I thought about supporting
> 
> - Creation (after instantiation?)
> - Configuration (before configure???)
> - Destruction (before dispose)
> 
> Thoughts?

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.  I don't think that is how we
should think about container extensions.

> To manage extensions I created a LifestyleManager class that 
> exposes events. I would like to enable 
> Context/Contextualization in Avalon.Net through extensions as 
> an eat-your-own-dog-food exercise. 
> 
> Anyway every ComponentFactory should rely on LifestyleManager 
> class as a handler. I don't know how to do that in a non-
> intrusive way and not dependent of a correct ComponentFactory 
> implementantion to everything works fine. Help!!!

The first place to start is the simple case.  Start with what you
_know_, not with what you're not sure about.  While it seems like
obvious advice, let's look at what we already have defined.

1) A container is responsible for the life of a component, and satisfying
    any and all dependencies.

2) A container is responsible for any aditional features that can be
    bolted onto an existing component.

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.

 From that point forward, we start to look at creature features.  What would
I like to do with my existing components that would help development, debugging,
management, etc.

 From thinking on those types of features, we would think on how to accomplish
those features.

For example, with the Instrumentation package, we can most likely bolt on
certain types of instrumentation without ever getting into the implementation
details of the component.  For example, how often is a method called, or how
long does the method take to process on average?  When we have identified a
feature that we know we will use in the near future, we can then look at what
is available to implement that.

Up until this time it is completely premature to define interfaces and how
they interact.  We simply don't have the appropriate information.


-- 

"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