cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] Serviceable considered harmful (was Re: XSP not workingin CVS head?)
Date Tue, 18 May 2004 09:01:23 GMT
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 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...)

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 

>>Also, how do IOC type 2/3 containers handle optional 
>>dependencies (e.g. TraxTransformer checking for the Deli component) ?

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 Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message