cool! thanks. Questions popping up immediately:
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.== 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.
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().=== 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().
cheers,
- Leo
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
