cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] Some notes about the "Real Blocks" issue
Date Sat, 16 Oct 2004 11:52:55 GMT
Guido Casper wrote:

> Bertrand Delacretaz wrote:
>> Le 16 oct. 04, à 11:14, Guido Casper a écrit :
>>> ...for a start it would be the easiest to just drop in 
>>> spring-core.jar. But we would have to make sure, that this cannot be 
>>> interpreted as an invitation to introduce other dependencies....
>> Dependencies on Spring in the Cocoon core are certainly not a good idea,
> Why not? Don't you like Spring's way of DI?

DI is exactly why why we *don't need* to depend on Spring APIs except at 
the very few places where a container has to be created.

That's the whole goal of turning Cocoon components into POJOs: have our 
code become totally independent on the container that hosts them. Let's 
use Tani for inter-blocks and Spring for intra-block. I one day we're 
not satified with them, we can just use something else without a single 
code change in components. Configuration file format may change, but 
providing an XSL to migrate it should be a piece of cake should it ever 

Now I agree that pure DI using setters is not always possible and one 
may sometimes need to do some lookup on the container. That's where 
strong dependencies may come in. But we have a solution with POJC, the 
plain old java container (see [1]) that's have been present in the JDK 
for years. And we can easily plug a hook into Spring that wraps a 
BeanFactory into a BeanContext thus achieving container-neutral 
component lookups.

No container dependency at all in our components. What's what we want to 
achieve, and we have the tools for it.



Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message