> From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]] > > 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 Component. 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 does? 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 consequence. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
