cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: [RT] Serviceable considered harmful (was Re: XSP not workingin CVS head?)
Date Tue, 18 May 2004 07:00:03 GMT
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


Mime
View raw message