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 Tue, 05 Mar 2002 14:09:08 GMT
Leo Sutic wrote:
> 
>>From: Berin Loritsch [mailto:bloritsch@apache.org]
>>
>>Leo Sutic wrote:
>>
>>>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?
>>
> 
> The current AbstractContainer puts all components in a hashmap and accesses
> them through that map. It also contains code to implement ComponentManager
> functions (ContainerComponentManager).
> 
> I'd like to factor out the parts dealing with aquiring the component
> handlers and separate it from the code dealing with how to manage
> those handlers once aquired.
> 
> As it is now, AbstractContainer has a lot of good, useful code, but it comes
> with too many strings attached. While it is possible to subclass it and
> override methods to get any behavior, the contract between AbstractContainer
> and its subclasses is a bit too big for me to be able to get "any behavior"
> via subclassing.

Ok.  I would like to see your proposal.



>>>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.
>>
> 
> What I want to achieve is that global settings should propagate down the
> hierarchy of containers. So if you set THREAD_TIMEOUT to 15000 for the
> root container, that should propagate to any child container.

That is exactly what I am working on.  When a Container is given its
context, it will be able to use that same context as the parent context
for the child container.  Basically, the hierarchy would go like this:

m_childContainerManager = new ContainerManager( m_context );
ContextManager cmanager = m_childContainerManager.getContextManager();
cmanager.setClassName( "org.apache.cocoon.sitemap.InterpretedSitemap" );
cmanager.setContextDirectory( new File(
      (File) m_context.get( Context.CONTEXT_DIRECTORY ),
      "mount/location/" )
);

m_childContainerManager.initialize();

As you see, you only need to override certain values.  The rest are
obtained from the parent context.  I am working in a fresh class to
provide this functionality (DefaultContainerManager).



>>If a container has child containers, it would have a ContainerManaager
>>for each child, and override the CONTEXT_DIRECTORY for each one.
>>
> 
> Yes, and probably set it to CONTEXT_DIRECTORY (as given in its own context)
> +
> childContainerName. So CONTEXT_DIRECTORY must be available to the container.

Of course.

>>>>YES!  Absolutely.  I want to remove the dependancies on marker
>>>>interfaces in general.
>>>>
>>>>
>>>I think marker interfaces are great
>>>
>>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.
>>
> 
> You'd have an ordering ThreadSafe < PerThread < Poolable < SingleThreaded,
> but yeah, I can see that we're trying to be a little too smart here.

Not to mention that it is quite awkward when some of those classes are
in framework, some are in Excalibur, but they are not all in one
package.  Furthermore, this way we don't have to change the library if
we find a new way to manage component instances (like I did with the
Per-Thread policy).



>>>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.
>>
> 
> Bring it on.
> 
> I'll have to start off by figuring out just what your intentions are for
> the different classes, so we don't get some skewed evolution.

It's in CVS now.  I didn't mean to commit it, but once I did, I figured
we might as well work on it there.  The DefaultContainerManager is where
the new stuff will be--but it isn't functioning yet.



>>BTW, ContainerManager crushes ExcaliburComponentManager in scalability.
>>Part of this is due to asynchronous management
>>
> 
> Like the InitComponentHandlerCommand? I searched but couldn't find where
> it was used. Maybe I have an older version.

:) Yes.  The InitComponentHandlerCommand is (or supposed is to be)
issued to the Command Queue.  The queue is attached to the
CommandManager which in turn executes the command.


-- 

"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