avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [Proposal] ECM / ECS / AbstractContainer
Date Mon, 04 Mar 2002 17:52:40 GMT
Leo Sutic wrote:
>>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
> 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 ();

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

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

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

That way, if you short-circuit the normal path, directly providing the
Configuration object, it can pick up from there.

> 3) Will the Container interface be a marker interface? (See question 7).

NO!  It is not required, but it is available to easily manage the
contents of the Context object.

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

YES!  Absolutely.  I want to remove the dependancies on marker
interfaces in general.

> 5) CONTAINER_CLASS isa component?

Not necessarily--but it can be.

> 6) CONTAINER_CLASS isa Container? Always / must be?

Again, not necessarily, but it can be.  Since we are trying to move away
from requiring marker interfaces in general, I do not want to enforce
this restriction.  The only requirement is that the Container is extends
Object (the default).

> 7) Will a component that implements Container be treated in a special way by
> the
>    Container that contains it? (See question 3).

No.  A Container is a Container is a Container.  If you implement
lifecycle interfaces, you have them applied.  If not, then nothing
special happens.  It is preferred for the Container to at least
implement Contextualizable so that it can get a reference to all the
helpful managers passed in.

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


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

View raw message