Sylvain Wallez wrote > > One of the big advantages of newer containers are the fact > that there's no container-specific API that components must > adhere to, thus theoretically allowing cross-container > reusability. The viral nature of Avalon APIs is something > many people are reluctant with when I explain them how to > develop new components in a Cocoon environment (yes, you'll > mostly see me here with a Cocoon-oriented mind). > > So this "dependency injection" opposed to "dependency lookup" > is what makes ECM look old-fashioned even if it provides > features today unavailable in newer containers, e.g. > component pools, and also some kind of selector-like > mechanism (yes, it's sometimes needed).
Yes, I think dynamic lookup is one of the major advantages of Avalon. You can decide at runtime which components you need. This is not possible with setter/constructor injection. > > So it would be good if one of the main missions of this new > Excalibur project was, as stated by "the history and future > of IOC", to build a modern and embeddable container that > provides a smooth migration path to the large number of > existing lookup-based component. Carsten's additions to > support injection to Fortress are a step in that direction. > A small and ugly step... Now, I think it makes sense to evolve Fortress and support both worlds (POJO components and "Avalon" components). POJO has the advantages mentioned above, but Avalon provides more than just components; you have IoC logging support, application context support, dynamic lookup, container hierarchies etc. Each of these features makes sense and I personally don't want to loose them :) There is one thing I more and more dislike. It's the lookup mechanism in Avalon. I tried to change/enhance this recently over at Avalon. Instead of using Strings for roles and having perhaps selectors, a simple lookup mechanism that takes the interface and a key into account would do the trick: lookup(Class, String key). This would remove selectors etc. make dynamic lookups more transparent, removes the need for the ugly roles strings on the interfaces and can help with classloading problems. I still think, that if we have such a lookup mechanism and enhance Fortress here and there a little bit, it would be the ideal candidate for Cocoon and Cocoon does not need to write it's own container anymore - which would imho be great. But this is just my opinion about this topic... Carsten --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Apache Excalibur Project -- URL: http://excalibur.apache.org/
