cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: more about properties in cocoon 2.2
Date Tue, 22 Aug 2006 22:43:33 GMT
Leszek Gawron skrev:
> 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?
I can't follow you here, what 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 
> implemented:
> protected abstract void refreshBeanFactory() throws BeansException, 
> IllegalStateException;
> protected abstract void closeBeanFactory();
> public abstract ConfigurableListableBeanFactory getBeanFactory() throws 
> IllegalStateException;
> I know there are lot's of methods from other interfaces but they are 
> already taken care of. Is that such a burden?

The AbstractApplicationContext certainly simplify things. Still 
implementing the ConfigurableListableBeanFactory that the abstract 
getBeanFactory() returns is a considerable amount of work compared to 
just implement a BeanFactory.

>> 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 :)

No we don't want a pluggable core. But in my POV we shouldn't have a 
tight integration with any container. After all the main promise with 
Spring is that it is a stable and popular DI container. We should 
embrace the fact that it is a DI container and refactor Cocoon so that 
components use DI instead of the the service lookup pattern as far as 

Cocoon will be much easier to maintain and reuse parts of if we avoid 
the dependency on huge container interfaces.

Now, thinking about it, the discussion seem to have started with having 
a CocoonApplicationContext instead of a CocoonBeanFactory. Thinking 
about it I don't have any problem at all with that. My only concern is 
that I don't want the sitemap servlet to depend on such a fat interface.

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

As I'm not trying to block having a CocoonApplicationContext, the above 
points shouldn't be a problem.

> 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 :)

Users should of course be able to do whatever they want, shooting 
themselves in their foot included ;) For Cocoon I would prefer following 
generally accepted best practices and minimize dependencies as far as 

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

The OSGi stuff certainly is not intended to be just a proof of concept, 
but something useful. That it is not useful yet is because there still 
are work left to be done.


View raw message