cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ugo Cei <>
Subject Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)
Date Thu, 22 Jul 2004 08:12:34 GMT
Il giorno 22/lug/04, alle 01:28, Stefano Mazzocchi ha scritto:

> I say we write our stuff and be done with it once and forever.

I agree with you on one thing here. Depending on an external community 
for our foundations is a BIG risk. But I also want to balance risks 
against benefits. Spring is actively developed, well documented, widely 
used and thouroughly tested. Can you say the same of Kernel?

Now, I don't want this thread to escalate into a flame war of the kind 
"my container is better than yours". I actually want to point out what 
is the greatest benefit of Spring, in my mind. It is the fact that you 
can write components that don't depend on it and yet be managed by it. 
If you take a look at the small code sample that I wrote, you can 
easily see that most of what I did consisted in *removing* things. I 
removed all dependencies on Avalon, all of "extends AbstractLogEnabled 
implements Serviceable, Poolable, Recyclable, Whateverable". I removed 
looking up collaborators via a ServiceManager and instead injected them 
(like the XMLParser) via a setter. And I did *not* substitute them with 
Spring classes and interfaces.

So, what you're left with is a handful of beans that can be deployed in 
Spring but, if Peter wants to deploy them in Pico/Nanocontainer 
instead, fine. It should be easy. There are no dependencies on the 
container (see also point 1.4.1 of the manifesto).

(Note to self: rewrite unit tests so that they don't depend on 

To sum it up, Kernel is fine if it supports Type 2 and/or Type 3 
Dependency Injection (that is constructor and/or setter based). It 
would better if it had more tests, but hey. And it is fine if it moves 
forward, but I won't be the one to move it, because I don't have 
neither the expertise nor the time needed to write a container. I use 
Spring in my daytime job for implementing applications, so my knowledge 
of it is growing, and I have some time to rewrite some Cocoon 
components to be compatible with a dependency-injection approach. If 
this means, as I hope, that they can be deployed in Spring, Pico/Nano, 
Hivemind or Kernel without changes, we can take some time to rehash all 
the alternatives and decide which one is best. In the meantime, let's 
fscking do something ;-).


Ugo Cei -

View raw message