avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: ContainerManager (was: RE: [Proposal] ECM / ECS / AbstractContainer)
Date Mon, 04 Mar 2002 19:54:27 GMT
Sorry for the noise earlier, I meant to print, and I hit reply/send ?!?

Leo Sutic wrote:
> 
>>From: Berin Loritsch [mailto:bloritsch@apache.org]
>>
>>Leo Sutic wrote:
>>

>>>I take it then, that this would be done just as above. The component
>>>would have a CM created via the ContainerManager.
>>>
>>THere is an AbstractContainer class that takes care of the default
>>implementation of this.  It builds all the component handlers and such
>>for the Container.  The COntainerManager merely manages the instance
>>of the Container.  It has its ComponentManager to help resolve config
>>files.
>>
> 
> I would like to split this one and break out the get and has methods.
> 
> AbstractContainer: Provides methods for obtaining handlers to components.
> AbstractManager  : Provides methods for accessing component handlers.
> 
> Basically, AbstractContainer.m_mapper would be AbstractManager.m_mapper,
> and the rest of the class follows as needed to compile.


Why?  What does it gain?




>>>Questions:
>>>
>>>1) How do I pass a parent CM to the new CM that I create via the
>>>ContainerManager?
>>>
>>:)  I am working on that.  Basically, if I pass it in the constructor,
>>or the ContextManager, I can handle that quite easily.
>>
> 
> Or pass it in if the created container implements Composable as the
> container
> is being put through the lifecycle steps. The container would
> get the parent cm in compose. The parent cm is passed to the
> ContainerManager via the Context (see below).
> 
> I think the ContainerManager must allow for more overrides - one should, as
> with the configuration below, always be able to pass in a pre-generated
> CM, or Context, or Configuration.

Yep.  see below.

> 
> 
>>>2) How do I pass a non-file Configuration to the ContainerManager?
>>>
> (Useful
> 
>>>in the second case.)
>>>
>>Good question.  My thoughts are to make the ContainerManager use the
>>ContextManager.
>>
> 
>>It would retrieve the URI from the context and retrieve
>>a Configuration, and store the configuration in the Context.  Next, it
>>would pull that configuration and generate the resource.
>>
> 
> Or:
> 
> public class ContextManager {
> 
>   ...
> 
>   public void buildConfigurationFromFile (String path) {
>     ...
>     // Build the configuration from the path, resolving it relative to the
>     // context base URI and so on.
>     ...
>     setConfiguration (newlyBuiltConfiguration);
>   }
> 
>   public void setConfiguration (Configuration configuration) {
>     // put the configuration into the context
>     ...
>   }
> 
>   ...
> 
> }
> 
> and replace the constructors of ContainerManager with:
> 
>   public ContainerManager( final Context initParams,
>                            final Logger primordialLogger )

I was actually in the process of performing this change.  Basically
allowing for the exchanging of ContainerManager implementations--that
are specific to a certain platform.  You can override methods to
remove the need for reflection--although the default implementation
is available.

Also, the ContainerManager is being split into interface and
implementation....

> The ContainerManager will then use the objects in the initParams to
> initialize the container. That is, initParams contains a configuration,
> it contains Parameters, a ComponentManager and so on. It also
> contains a Context that will be passed on to the created container.

:)  In essence yes, that is what is happening.



> That Context needs some post-processing, since the created container must
> be able to use the Context it recieved in contextualize to create its
> own sub-container.
> 
> Therefore, the Context actually passed on to the container is
> 
>   Context as given in the initParams parameter to the
>            ContainerManager constructor
>                           +
>           some elements of initParams itself.
> 
> The parts of initParams that should be passed on to the container are
> basically those that the container can not guess itself, but that
> are needed to create a sub-container:
> 
> CONTEXT_DIRECTORY
> WORK_DIRECTORY
> LOGKIT_CONFIG
> THREADS_CPU
> THREAD_TIMEOUT

There are defaults for these values--but they are meant to be overriden.

I.e. THREADS_CPU defaults to 2, THREAD_TIMEOUT defaults to 15 seconds,
LOGKIT_CONFIG defaults to "context://logkit.xconf", work directory
defaults to "/tmp", and context directory defaults to "./".

If a container has child containers, it would have a ContainerManaager
for each child, and override the CONTEXT_DIRECTORY for each one.



>>>4) Is it your intention to not use the Lifestyle interfaces ThreadSafe
>>>
> etc.
> 
>>>   any more and replace them with handler attributes in the
>>>
> configuration file?
> 
>>YES!  Absolutely.  I want to remove the dependancies on marker
>>interfaces in general.
>>
> 
> I think marker interfaces are great: You will need to document the type
> of handler a component uses anyway, so why not make it part of the component
> class? C#, for example, allows attributes to be set for every object in the
> system. Java has interfaces. It would be unwise to throw it away.
> 
> I'd go for a handler="..." override and an autodetect based on marker
> interfaces.
> 
> No big deal - the ContainerManager is such an improvement that this is
> trivial.

The problem is when you have a deep implementation or interface
hierarchy.  If any superclass implements one lifestyle interface, then
you cannot change it down the line.

Given a situation where you have an interface that is threadsafe
according to its signature (i.e. only one method, or a stateless
component), we might have in implementation that is declared ThreadSafe.
Someone else might come along and extend it, but the new implementation
must be PerThread or Poolable at the least.

You cannot safely change it.  Therefore by declaring it in the "handler"
attribute, you don't loose that very important information in the
inheritance hierarchy.  In the end, this approach is more predictable,
and scales better in large projects.



>>>>Nothing stops you from directly using the ComponentHandler classes.  I
>>>>would suggest you make all of them ThreadSafe, so you don't have any
>>>>funny logic and make things easy on yourself....
>>>>
>>>>
>>>That's pretty much my conclusion, too.
>>>
>>>But for future work I will need the ContainerManager or something
>>>exactly like that.
>>>
>>:)
>>
>>I'm working as fast as I can, but if you want to help, I would
>>appreciate it.
>>
> 
> I'm in.

Excellent!  I can send you the current rework progress (that has come to
a standstill due to some fires I have to put out at work) off line,
maybe you can flesh it out and get it committed.


BTW, ContainerManager crushes ExcaliburComponentManager in scalability.
Part of this is due to asynchronous management, and part of this has
to do with special attention given to reduce thread contention in the
critical path.  ECM brought us a long way, but ContainerManager will
bring us to the next level of ease of use and scalability.



-- 

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


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


Mime
View raw message