cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <>
Subject Re: more about properties in cocoon 2.2
Date Tue, 22 Aug 2006 08:56:25 GMT
Daniel Fagerstrom wrote:
> 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.

Why not expose core also with a lighter interface?

> 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.

AbstractApplicationContext contains only 3 methods that need to be 

protected abstract void refreshBeanFactory() throws BeansException, 

protected abstract void closeBeanFactory();

public abstract ConfigurableListableBeanFactory getBeanFactory() throws 

I know there are lot's of methods from other interfaces but they are 
already taken care of. Is that such a burden?

> 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.

My POV may not be accurate but from where I stand if we already have 
chosen a stable container why not go for tight integration. After all 
you do not want pluggable core :)

I was hoping that my migration to 2.2 will ease the setup and 
configuration of a spring context I have in every application. It turned 
out that because of the fact that cocoon does not expose itself as 
WebApplicationContext in ServletContext I had to separate my spring 
beans again:

- none of BeanFactoryPostProcessors work because they are automatically 
applied only in case of ApplicationContext

- none of spring based servlet filters work because they require the 
application context to be registered at servlet context. So you won't be 
using hibernate3.OpenSessionInViewFilter or acegi.FilterToBeanProxy. How 
annoying is that?

- you do not have access to application events

- you do not have access to MessageSources

- you do not have access to cocoon components anyway.

User writing a block will not be able to use the same techniques he/she 
was used to when using pure spring approach. We signal users "We are 
using spring in core. Nice huh? You can also use it in spring now and 
that is pure fun". And then they hit the wall like I did :)

Correct me if I am wrong but we are not heading for a Proof-Of-Concept 
(which OSGi right now seems to be) but rather for something useful.

Please do not take anything I say offensive (my english is not fluent so 
some phrases may not reflect the proper emotion amount :)).

Leszek Gawron, IT Manager                          MobileBox sp. z o.o.
+48 (61) 855 06 67                    
mobile: +48 (501) 720 812                       fax: +48 (61) 853 29 65

View raw message