> From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
>
> 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.
> 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....
Cool.
> > 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.
> 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.
> >>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.
> > 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.
> 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.
/LS
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
