avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Sutic" <leo.su...@inspireinfrastructure.com>
Subject ContainerManager (was: RE: [Proposal] ECM / ECS / AbstractContainer)
Date Mon, 04 Mar 2002 19:05:52 GMT

> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Leo Sutic wrote:
> >
> > And I now have a completely initialized component manager
> > inside the containerManager. Then I do a:
> >
> >     ComponentManager myManager =
> >         (ComponentManager) containerManager.getContainer ();
> I want to move this part to a ContextManager, so that it makes it easier
> to reuse instances of PoolManager et. al. from a parent container.
> > and when I want to process a request, I can look up the Processor
> > (for example) component in myManager and pass it the required
> parameters.
> The way I would envision it for something like Cocoon where the Cocoon
> object *IS* a processor, I would do this in the servlet code:
> Processor cocoon = (Processor) containerManager.getContainer();
> I would not expose the ComponentManager to the outside world (Subversion
> of Control you know).
> > And now, I want to write a component that holds several other
> components.
> >
> > 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.

> > 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
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.

> > 2) How do I pass a non-file Configuration to the ContainerManager?
> > 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.


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 )

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.

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:


> > 4) Is it your intention to not use the Lifestyle interfaces ThreadSafe
> >    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

No big deal - the ContainerManager is such an improvement that this is

> >>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.


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

View raw message