Daniel Fagerstrom wrote:
Why not expose core also with a lighter interface?
I can't follow you here, what lighter interface?
Let's define that interface and allow block that do not use spring use
instead of ApplicationContext.
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.
That is why there is a DefaultListableBeanFactory that we could extend...
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.
Of course. What I meant writing 'tight integration with spring' was
allowing users to use other spring mechanisms/features like:
- orm support (with open session in view filters),
- security (acegi),
- MessageSources,
- event listeners.
Currently some of these features won't work because they are tied to
ApplicationContext.
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.
fantastic
--
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
