cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] Simplifying component handling
Date Wed, 04 Jan 2006 08:10:32 GMT
Giacomo Pati wrote:
> On Tue, 3 Jan 2006, Sylvain Wallez wrote:
>> Right. And the simplest and most consistent step to go forward is IMO 
>> to just use what's already there, providing a nice bridge to a 
>> rock-solid container used by thousands of people.
> If you mean Spring as the "rock-solid container used by thousands of 
> people" than tell me why are you using a Mac while "ten-thousands of 
> people use a IBM ThinkPad" ;-)

A very interesting comparison: Apple is currently moving to Intel CPUs!! 
Why so? Because PowerPC is a dead end for their market, as IBM makes no 
effort to produce good laptop CPUs. So Apple changes the engine, without 
changing what's unique to them.

This is exactly the same for Cocoon: Avalon is dead, and we all agree on 
this. So what's the point of adding dependency injection features to 
Avalon? It's like adding Intel instructions to a PowerPC to prepare 
migration. That's nonsense: you end up with a clumsy solution that 
smells like a DI container but is not, and provides a mix of injection, 
lifecycle interfaces and service lookup. Furthermore, it doesn't really 
encourage people to move away from Avalon as its features are still 
available to all components.

That's what I'm against this change to ECM: just as Apple has setup a 
bridge (Rosetta) to allow PowerPC and Intel code to run on the same 
hardware, let's have this bridge in Cocoon too. Want to use legacy 
components? Use ECM. Want to use dependency injection? Use Spring. Or 
Pico. Or Hivemind. The bridge can host whatever container manager you 
want, even if we should promote only one.

 From a user point of view, I'll be happy to see soon PowerBooks as 
powerful as ThinkPads. But there's actually much more to this switch: it 
won't take long before wine is ported to the Mac, so that we can use 
some applications that, like it or not, only exist on Windows. Yes: the 
comfort of the Mac, with is "deviant" compared to the vast majority of 
PCs out there, but the ability to suck Windoze applications when it 
makes sense.

This is the same with Spring: this is not only a DI container, but a lot 
of additional services to build applications. And also a lot of people 
that know it.

The Cocoon project, in its current state, really doesn't need yet 
another specific extension to its obsolete container architecture, that 
less than an handful of people will understand and be able to maintain. 
We need to move away from Avalon, so let's do it in a way that can bring 
in more people and use an engine that's known outside of cocoon-dev.

> I can understand Carsten as we've talked about it recently and we 
> share some common reservation about Spring (as Carsten has already 
> expressed). Maybe Carsten regrets having written that Spring bridge or 
> the motivation to write it was a business or marketing need not a 
> conceptual evolution.

I asked Carsten why he doesn't want to use the bridge that _he_ wrote, 
and would love to have his answer. Carsten?

> So, after your veto to the change Cartsten has proposed the only way 
> for him is to write another bridge that suits his needs. This is what 
> I was calling ECM+++.
> Admittedly I do not know how this bridging to Spring is done at all 
> and I cannot say whether or not a migration from one CM to another 
> will be possible to smooth this migration so that one day we can 
> deprecate the usage of Avalon components.

Have a look at the "spring-app" block.


Sylvain Wallez                        Anyware Technologies           
Apache Software Foundation Member     Research & Technology Director

View raw message