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
possible.
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
possible.
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.
/Daniel
