Carsten Ziegeler wrote:
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 3Are 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...)
This is a solution for RequestLifecycle component, but unfortunately doesn't answer all cases that are needed in Cocoon. Consider for example transformers. If transformer pools are managed on a object-per-request basis, we simply cannot chain two transformers of the same kind in a pipeline!
Also, how do IOC type 2/3 containers handle optional dependencies (e.g. TraxTransformer checking for the Deli component) ?Yepp.
Actually, this can be solved by considering constructor injection as required dependencies and property injection as optional dependencies.
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?
+1. ServiceSelectors and object pooling are areas where bean property injection simply cannot work (although I would love to be proven wrong!). Poolables can be partly avoided either using pool management events (e.g. request start/stop) or refactoring to factories, but ServiceSelectors require a particular API.
What has to be defined is if this selector API is defined by the application or by the container: is it a container feature, thus requiring dependencies of the code on the container, or is it a particular application component. The frontier is not that clear...
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
