Carsten Ziegeler wrote:

Sylvain Wallez wrote:


You have to consider two very different things:
- the Avalon framework APIs (LogEnabled, Serviceable, Configurable, etc.)
- the container that implements the framework behaviour


Although the container implementation may change, there's a strong commitment to the framework APIs as this is what we've used and invested in for many years.

So even if a new container comes with new features (e.g. IOC type 2/3), it will also have to implement the Avalon framework behaviour. We cannot trash years of use of this API overnight.


I don't want to freak out again but if you look at the discussions
about the block implementations, there were a lot of discussions
to also remove the framework api from the block system. So if you
want to use the benefit of blocks, you can't use the avalon
framework api for your components. And I still think this is bad.



I definitely think we'll find a bridge between them, e.g. manager.lookup("block:block-name:org.apache.cocoon.Role");


Anyways, if for example we would move to Fortress (without using
the meta-info stuff and keeping our current configuration files
which is possible!) we could add own lifecycle interfaces over
time and provide a smooth migration path to whatever comes with
blocks.



Yupp.

Sylvain

--
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }



Reply via email to