Leszek Gawron skrev:
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.
Ok, I understand.
My view on this is a little bit more far reaching, Cocoon should in the
future, IMO, not manage components anymore.
The main reason that Cocoon has been so tightly integrated with the
container is that one can define components in the sitemap. This in turn
depended on the view that "sitemap components" was a different concern
area than ordinary components. First it is questionable if that was such
a good analysis, second it is not true from a technical POV anymore.
Later it was made possible to define all kind of components in sitemaps,
and subsitemaps started to be used for modularization of applications.
While it worked reasonably well there where some problems with the
approach. Context handling for components is a really tricky question
that we still not have solved completely. Also it required us to do a
lot of own work in the component container area as the concepts we use
are far away from mainstream use of containers.
For modularization we have a much better solution in term of the blocks
architecture. Currently it has some dependencies on OSGi, but it is
mainly based on DI and the servlet interfaces. I'm working on removing
the OSGi dependencies an make it Spring manageable and usable in 2.2. As
soon as this is done we don't need sub sitemaps as a modularization tool
anymore.
IMO we should then deprecate component management in sitemaps. This will
simplify the sitemap engine considerably and component management will
not be our communities responsibility anymore, we will just provide a
number of Spring manageable (or even whatever-manageable) DI components.
With this in mind I don't think that we need to define any interface for
what parts of Spring we want to make available for blocks writers. As
all components will be managed of a Spring container that is setup by
the user outside of Cocoon proper, the block author could use whatever
they like.
So there will be no limitations of what you can use. A completely
different concern is that we as a community should following best
practices and depend on as small interfaces as possible. So instead of
writing a component that depends on all of the ApplicationContext we
should write components that only depend on the subinterfaces that we
actually need.
All this is about separation of concern. Component containers should IMO
not be Cocoon's concern.
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...
Not for this particular use case AFAICS. What we are talking about is a
OSGi-Spring bridge, that make OSGi services available through the
BeanFactory interface, that is something quite different from what the
DefaultListableBeanFactory does.
/Daniel
