avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <leosim...@apache.org>
Subject Re: [A4:Fortress] Design scratchings
Date Tue, 21 Jan 2003 16:42:21 GMT
cool! thanks. Questions popping up immediately:

> == Asyncronous Management ==
> 
> Fortress makes use of the Event package's CommandManager so that
> all components can be started up immediately, but it is done in
> the background.  That means that components are still starting
> while Fortress is ready to work.  If a component hasn't been
> started yet before it is needed, then Fortress will make sure it
> starts before it turns over the requested component.  It will
> also make sure no component gets started twice.

so there's proxies which defer to some kind of dependency management 
code, yes? Where is that code right now? Phoenix explicitly builds and 
maintains a directed graph; haven't found this code in fortress yet. I'm 
talking about the service() contract of course.

> === Why Not Set Up a Standard Container Interface? ===
> 
> Each domain has its own needs.  For instance, Cocoon is based on a
> request/response processing model.  Component based tools are based
> on a useage model.  Swing based Apps are based on other models.
> There is no one size fits all solution, and Fortress can be used in
> all of these solutions.  As an interim solution, the DefaultContainer
> does have one public method exposed: getServiceManager().

OK. I'm still wondering (the why and the how and the need) about the 
seperations between Container, AbstractContainer, DefaultContainer and 
MyCustomContainer. In particular, AbstractContainer doesn't handle 
configure().

cheers,

- Leo



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