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
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?
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 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
