Sylvain Wallez wrote: > > I agree with this. Now IOC type 2/3 containers haven't solved > the problem of non thread-safe components, and more generally > relations between components of different lifestyles (e.g. > ThreadSafe and Poolable). And Cocoon cannot live without > this, unless some major refactoring leading to Cocoon 3 > Are you sure? I haven't looked very deeply into it, but I think e.g. HiveMind can do this. They create a proxy around a poolable component and the container is notified when a request starts and stops. So after the request starts and you access the proxy a component is fetched from the pool. When the request stops all components are put back to the pool. (I think it's working this way...)
> Also, how do IOC type 2/3 containers handle optional > dependencies (e.g. > TraxTransformer checking for the Deli component) ? > Yepp. > Finally, what frightens me with Spring configuration is the > need to explicitely declare all dependencies. Imagine the > size of a Spring-style cocoon.xconf... > And how can you do the highly dynamic composition of our pipelines? Every technique has it's weaknesses. Interface injection (Avalon) has the problem that your components depend on the framework and setter/constructor injection have other problems. So imho you can't simply say "this or that is the right way". There are situations where one or the other makes more sense. So why not having a container that can simply both? Carsten
