ContainerManager et al.

[Leo Sutic <le...@inspireinfrastructure.com>]

Berin,

I'm starting to dig into the CM code. Just a few quick questions:

1) RootContainerManager / DefaultContainerManager: The difference is that
   the RootCM has ownership of the m_threadManager etc., right?

2) I intend to have RootContainerManager extend DefaultContainerManager,
   as the only difference is that the RootCM has owvership of the
   managers - the code that creates the container is shared.
   Alt: Factor out those parts to an AbstractContainerManager.

3) ContainerManager gets:

    String CONTAINER_CONFIG         = "container.configuration";
    String CONTAINER_CONTEXT        = "container.context";
    String CONTAINER_PARAMETERS     = "container.parameters";

   which will be passed on to the created container.

4) The ContainerManagers are altered to accept a single Context
   object in their constructors.

5) The ContextManager gets code to load configurations from URI's, 
   etc. as I described in my previous mail.

/LS

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: ContainerManager et al.

[Berin Loritsch <bl...@apache.org>]

Leo Sutic wrote:
> Berin,
> 
> I'm starting to dig into the CM code. Just a few quick questions:
> 
> 1) RootContainerManager / DefaultContainerManager: The difference is that
>    the RootCM has ownership of the m_threadManager etc., right?

The difference is RootContainerManager is the first version I created,
and DefaultContainerManager is not finished yet.

Root works off of a Properties file, while Default works off of context.

It can maintain ownership of the thread manager et. al., but only does
so if there is none accessible in the Context.



> 2) I intend to have RootContainerManager extend DefaultContainerManager,
>    as the only difference is that the RootCM has owvership of the
>    managers - the code that creates the container is shared.
>    Alt: Factor out those parts to an AbstractContainerManager.

:)

I am working towards having Default be the way to go--I just had to
pause.



> 3) ContainerManager gets:
> 
>     String CONTAINER_CONFIG         = "container.configuration";
>     String CONTAINER_CONTEXT        = "container.context";
>     String CONTAINER_PARAMETERS     = "container.parameters";
> 
>    which will be passed on to the created container.

Yep.  I eventually want a ConfigurationManager that manages the config
object trees and monitors the sources so that if they ever are updated,
we can trigger reconfiguration events.  Additionally, the Container
would be able to communicate with the ConfigurationManager and alter the
configuration objects that belong to it.  That way configuration can be
maintained programmatically.  Servers that require configuration for
modules that are loaded at run time need to record the config entry
for the new module.



> 4) The ContainerManagers are altered to accept a single Context
>    object in their constructors.

Right.  The Root works as is, but uses a Parameters object.  I want to
move toward the Context/ContextManager approach.

> 5) The ContextManager gets code to load configurations from URI's, 
>    etc. as I described in my previous mail.

Pretty much.


-- 

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


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>