You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by hammett <ha...@uol.com.br> on 2003/09/11 03:27:05 UTC
Container Extensions
Whichs phases a container should exposes to enable developers
to hook up and extend the lifecycle of components?
I thought about supporting
- Creation (after instantiation?)
- Configuration (before configure???)
- Destruction (before dispose)
Thoughts?
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!!!
hammett
---
Acabe com aquelas janelinhas que pulam na sua tela.
AntiPop-up UOL - É grátis!
http://antipopup.uol.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Container Extensions
Posted by hammett <ha...@uol.com.br>.
From: "Berin Loritsch" <bl...@apache.org>
> Granted this is a complicated way of doing things, but as always focus on
> the simple stuff first.
Got it.
> 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.
No no.. It is there:
namespace Apache.Avalon.Framework
{
using System;
<...>
public interface ILookupManager
{
object this[string role]
{
get;
}
void Release(object resource);
}
I swear I didn't touched it :-)
> 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.
Its a noble objective, but are you sure we gonna achieve it? For sure it's
not a good thing the container expect a correct use from the component
consumer, but I don't see another way..
hammett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Container Extensions
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
>
> Berin Loritsch wrote:
>
>>
>> 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.
>
>
>
> Ummm - so how are you managing the actual release of components? Even
> if a component is a singleton, the container can track usage based on
> release notifications by consumers and determine if the singleton
> component can be decommissioned.
It would be more of a garbage collection process so to speak. Granted,
with the use of proxies, the proxy would have to be smart enough to block
until the backing component was loaded in...
Nevertheless, since C# is a new effort, Let's worry about the front side first.
--
"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
Re: Container Extensions
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
>
> 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.
Ummm - so how are you managing the actual release of components? Even
if a component is a singleton, the container can track usage based on
release notifications by consumers and determine if the singleton
component can be decommissioned.
Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Container Extensions
Posted by Berin Loritsch <bl...@apache.org>.
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
Re: Container Extensions
Posted by Hamilton Veríssimo de Oliveira <ho...@bvtibusiness.com.br>.
> 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
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: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: RES: RES: Container Extensions
Posted by Berin Loritsch <bl...@apache.org>.
Hamilton Veríssimo de Oliveira wrote:
>
> But that's the point. How the component will access it's dependencies?
> Through look up I think.
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).
> The component initialization protocol will be performed for this
> dependent component as it will for any other component - on demand -
> don't they? If don't, it will force us to threat them different,
>
> - creating a separate LookupManager
> - put the real instances of each dependent component there
> - praying for someone to dispose them
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. I have experienced
some bugs where the container locked up on shutdown that went away when
we ensured everything was in the proper order.
All components should have their own "LookupManager" so that they only
see what they need to see. Fortress is somewhat crippled in that respect.
As to your other two bullets:
- "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).
- "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.
>
> The container ensuring the environment sanity is a good thing, but I
> can't see how to implement a different behavior for dependents
> components. Maybe my nighlty studies of Fortress and Merlin show me
> where I'm wrong.
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?
>
>
>>BTW, did you get the mail I sent you RE: getting proper info for your
>
> CVS access?
>
> I didn't. To which email you sent? I don't work for Cimcorp anymore...
> :-(
Ahh, that is where I sent it. What email is best for you?
--
"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
RES: RES: Container Extensions
Posted by Hamilton Veríssimo de Oliveira <ho...@bvtibusiness.com.br>.
-----Mensagem original-----
De: Berin Loritsch [mailto:bloritsch@apache.org]
> Some of the very necessary features that containers do these
> days is to verify that the environment is sane. While we think
> we know all the components that are needed for a system, from
> time to time we may find that one is missing for some reason.
As a sanity check it's a nice feature.
> So as an example, if I have a component that retrieves data
> from an expensive resource (like a database), I might have the
> component use a cache component. If the cache component exists,
> but has not been loaded and properly configured in time, then
> the data component will fail.
But that's the point. How the component will access it's dependencies?
Through look up I think.
The component initialization protocol will be performed for this
dependent component as it will for any other component - on demand -
don't they? If don't, it will force us to threat them different,
- creating a separate LookupManager
- put the real instances of each dependent component there
- praying for someone to dispose them
The container ensuring the environment sanity is a good thing, but I
can't see how to implement a different behavior for dependents
components. Maybe my nighlty studies of Fortress and Merlin show me
where I'm wrong.
> BTW, did you get the mail I sent you RE: getting proper info for your
CVS access?
I didn't. To which email you sent? I don't work for Cimcorp anymore...
:-(
hammett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: RES: Container Extensions
Posted by Berin Loritsch <bl...@apache.org>.
Hamilton Veríssimo de Oliveira wrote:
> -----Mensagem original-----
> De: Berin Loritsch [mailto:bloritsch@apache.org]
>
>
>>Check out the Directed Acyclic Graph utilities in Fortress
>>(**.fortress.**.dag). Porting that to C# will help you find
>>violations of the first guideline, as well as help you order
>>your dependencies so that they are loaded and disposed of in
>>the proper order.
>
>
> Humm.. I'll do it tonight. But, before that, what is the meaning of
> loading a dependent component?
> It will be made available through look ups anyway, right? Maybe
> dependencies handling are a Java issue, where the order of class loading
> is a important issue. We won't have this kind of problem in .net. At
> least while we don't support a kind a hot deployment.
Some of the very necessary features that containers do these days is
to verify that the environment is sane. While we think we know all the
components that are needed for a system, from time to time we may find
that one is missing for some reason.
With the proper dependency information (i.e. one component requires
another to function), the container can perform a sanity check as well
as ensure that the components are initialized in an order where the
required component will be available before the component that needs
it is instantiated. That way there is no issue with component initialization.
Wouldn't you as a user prefer to see the container tell you that it is
missing a component and what component it is missing rather than trying
to guess?
So as an example, if I have a component that retrieves data from an
expensive resource (like a database), I might have the component use
a cache component. If the cache component exists, but has not been
loaded and properly configured in time, then the data component will
fail.
At least that is how we are using it on the Java side.
BTW, did you get the mail I sent you RE: getting proper info for your
CVS access?
>
>
>>>by using a LifestyleManager to centralize invocation of lifestyle
>>>methods.
>>>
>>
>>Lifestyle is more like "transient", "singleton", "pooled", etc.
>>Lifecycle is the initialization, destruction, etc.
>
>
> I'll change its name tonight ;-)
:) Ok.
--
"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
RES: Container Extensions
Posted by Hamilton Veríssimo de Oliveira <ho...@bvtibusiness.com.br>.
-----Mensagem original-----
De: Berin Loritsch [mailto:bloritsch@apache.org]
> Check out the Directed Acyclic Graph utilities in Fortress
> (**.fortress.**.dag). Porting that to C# will help you find
> violations of the first guideline, as well as help you order
> your dependencies so that they are loaded and disposed of in
> the proper order.
Humm.. I'll do it tonight. But, before that, what is the meaning of
loading a dependent component?
It will be made available through look ups anyway, right? Maybe
dependencies handling are a Java issue, where the order of class loading
is a important issue. We won't have this kind of problem in .net. At
least while we don't support a kind a hot deployment.
> > by using a LifestyleManager to centralize invocation of lifestyle
> > methods.
> >
> Lifestyle is more like "transient", "singleton", "pooled", etc.
> Lifecycle is the initialization, destruction, etc.
I'll change its name tonight ;-)
hammett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Container Extensions
Posted by Berin Loritsch <bl...@apache.org>.
hammett wrote:
> ----- Original Message -----
> From: "Berin Loritsch" <bl...@apache.org>
>
>
>>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)
General guidelines:
* Never allow circular dependencies with components. They don't work, and
if two or more components are so intertwined, they should be merged into one
component.
* Components can have dependencies on components with dependencies. Don't
limit the user.
* Not all dependencies are required--you can choose how you want to handle them.
(i.e. load if available, or never load unless explicitly told to do so).
Check out the Directed Acyclic Graph utilities in Fortress (**.fortress.**.dag).
Porting that to C# will help you find violations of the first guideline, as
well as help you order your dependencies so that they are loaded and disposed of
in the proper order.
Considering that we have treaded this ground several times before with the Java
side, you definitely have some good resources available to you.
>
> 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.
Lifestyle is more like "transient", "singleton", "pooled", etc.
Lifecycle is the initialization, destruction, etc.
--
"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
Re: Container Extensions
Posted by hammett <ha...@uol.com.br>.
----- Original Message -----
From: "Berin Loritsch" <bl...@apache.org>
> 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: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Container Extensions
Posted by Berin Loritsch <bl...@apache.org>.
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