cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <>
Subject RE: [Design] ContainerManager is under fire--let's find the best resolution
Date Mon, 10 Jun 2002 05:23:13 GMT
> From: Stefano Mazzocchi [] 
> Now, you (and Berin) were suggesting that the CM be extended 
> to provide a single point of contruction control not only for 
> Avalon components, but also for those legacy objects that 
> might request non-simple contruction control (such as pooled 
> resources).

Stefano, You missed the last discussion we had on the subject
back in January (if I recall correctly).  There is a good backgrounder
on the discussion and rationalization of using Object instead of

The fact of the matter is that if you describe the component
model correctly in terms of parents, children, and peers; then
you don't need to name your compoennts "Component".

Consider the CORBA architecture.  It is a component architecture,
as is EJBs.  Both of them have their lookup mechanisms--but if we
want to use them directly in an Avalon system, then we have to
be able to either generate proxy objects to implement Component
or we have to modify the original sourcecode.  That's a lot of
work to enable the seamless integration with legacy component
systems.  CORBA components can be accessed via JNDI just as EJB
components.  Why should we place an artificial limitation on
Avalon components that no other public component architecture

The ServiceManager already exists, it represents what we want--
read more than just Cocoon.  It isn't going to change, and it
solves a lot of problems without introducing any of serious

To unsubscribe, e-mail:
For additional commands, email:

View raw message