cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: more about properties in cocoon 2.2
Date Tue, 22 Aug 2006 08:24:49 GMT
Carsten Ziegeler skrev:
> Leszek Gawron wrote:
>   
...
>> One VERY important question concerning cocoon core? Why is it based on 
>> spring's BeanFactory and not on ApplicationContext? 
>> I propose to switch from CocoonBeanFactory to CocoonApplicationContext. 
>> WDYT?
>>     
> I'm +1 for this - the original code I wrote actually used a
> CocoonApplicationContext. Daniel had some concerns about it (I think it
> was mainly about too many dependencies) and we switched to the simpler
> bean factory. Perhaps Daniel recalls why we switched back?
>   
The main reason is that the Spring-OSGi bridge needs to implement 
whatever container interface that the core uses. While it wasn't that 
much work to implement a bridge that implemented the BeanFactory (and 
some small extra interfaces), it would be a large amount of work to 
implement the huge amount of methods that the Spring ApplicationContext 
contains.

Also, as you write, I do have concerns about big dependencies. One of 
the main ideas with using a DI container like Spring is to reduce or 
even remove the dependencies on the container. To then start to depend 
on a huge interface like the ApplicationContext seem to me to be a step 
in the wrong direction.

If we really need to depend on the ApplicationContext, we should only do 
that in small, isolated parts of our code. Everywhere else we should 
avoid container dependencies and try to use DI instead, or at least only 
depend on small interfaces.

We already have all the experiences we could ask for about the problems 
one get while depending on a particular container (Avalon) :/, so to me 
it seem like a bad idea to repeat these mistakes with Spring instead of ECM.

==========

Now, having said that, I'm completely aware about that the core still is 
to complicated. IMO we need to take the consequences of our move to 
Spring and try to remove as many Avalon dependencies as possible. The 
ideal would be to remove all Avalon dependencies from core and just have 
an optional back compatibility block that users that depend on Avalon 
interfaces could use.

The current mix of Spring management and Avalon life cycles in the core 
is just to complicated.

/Daniel


Mime
View raw message