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 Wed, 23 Aug 2006 08:54:39 GMT
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 

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.


View raw message