avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Sutic" <leo.su...@inspireinfrastructure.com>
Subject RE: [Proposal] ECM / ECS / AbstractContainer
Date Mon, 04 Mar 2002 17:00:38 GMT


> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> Leo Sutic wrote:
> >
> >>From: Leo Simons [mailto:mail@leosimons.com]
> >>
> >>Basically, what you are proposing is to create a hierarchy of
> >>ECMs/ECS rather than a single-level-deep structure, IIUC. The
> >>advantage of this is that using a tree instead of a map results
> >>in better maintainability in larger projects. Right?
> >>
> >
> > That would be one possiblity, and I could make some arguments
> > for this, but what I want is to factor out the "this component
> > can have subcomponents" behavior from ECM/ECS. That is the primary goal.
> >
> > Both ECM and ECS now have a getComponentHandler method, for example.
> > Both of them implements LogKitManageable, Contextualizable etc. for
> > the sole purpose of passing on the obtained LogKitmanager, Context, etc.
> > to the component handlers.
> >
> > What I want to do is create a common superclass for ECM and ECS
> > and move that code there.
> >
> > So to split the questions:
> >
> >  1) Should the common code of ECM and ECS be factored out?
> >     This would make it easier to write ComponentSelectors
> >     and ComponentManagers.
>
>
> Yes, but don't call it AbstractContainer.  It will confuse things
> when the new ContainerManager/Container code is ready for prime
> time.

Berin,

what is your estimate for the ContainerManager/Container code? I
just found it in excalibur.system (had been looking in
excalilbur.container before), and if I'd much rather we got that
stuff going than waste my time with ECM/ECS.

Just a quick check that I understand the code correctly (it is beautiful,
BTW):

If I write a servlet, I'd first grab some parameters from
some file (like, number of threads per CPU, etc...). Since
I want to use the MyComponentManager class, I set CONTAINER_CLASS
to "MyComponentManager", which is a FQCN. Then I do:

    ContainerManager containerManager = new ContainerManager (parameters);

And I now have a completely initialized component manager
inside the containerManager. Then I do a:

    ComponentManager myManager =
        (ComponentManager) containerManager.getContainer ();

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.

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.

Questions:

1) How do I pass a parent CM to the new CM that I create via the
ContainerManager?
2) How do I pass a non-file Configuration to the ContainerManager? (Useful
in
   the second case.)
3) Will the Container interface be a marker interface? (See question 7).
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?
5) CONTAINER_CLASS isa component?
6) CONTAINER_CLASS isa Container? Always / must be?
7) Will a component that implements Container be treated in a special way by
the
   Container that contains it? (See question 3).

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

/LS



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