cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] Some notes about the "Real Blocks" issue
Date Wed, 13 Oct 2004 21:09:02 GMT
Ugo Cei wrote:

> Folks,
> here are some notes I jotted down today while on the train and later 
> on the plane, on my way back home from the GT, on the issues we 
> discussed Monday WRT "Real Blocks", Butterfly, Kernel (Tani), Spring, 
> blah blah blah
> Take it as just an outline to fill with your 
> opinions/suggestions/critiques. As soon as it starts coalescing into 
> something sensible, we should put it on the Wiki.

Damn, I also prepared a RT on this subject while in the plane this 
evening, in a different style. It would be interesting to split its 
content in the different items of our plan. I won't be much available 
until next wednesday, so here it is...

The original subject is "[RT] Towards a POJO-based Cocoon"

There was a panel discussion during the GT hackaton to finally decide 
what we want the kernel and the Cocoon component model to be.

The starting consensus that drives all the rest is that we no more want 
to explicitely depend on a container API. Avalon was the state of the 
art 4 years ago, but things have changed a lot since then both 
technically with the emergence of dependency injection (DI) and socially 
with the problems that led to the death of the Avalon community. This 
consensus means that, in order to be future-proof, both blocks and 
components inside blocks must be POJOs (plain old java objects) hosted 
by a container providing dependency injection. That is the only way that 
will allow components to resist a major change in the container used, 
should it happen again.

There are two levels in containment in Cocoon, corresponding to 
different needs:

- the kernel, which is the root container that hosts blocks: it must 
provide classloader shielding of the blocks contents, wiring of blocks 
through DI and managing static factories (jaxp/trax/commons logging 
etc). Thats basically all. We decided to abandon, at least for now, the 
idea of hot deployment of blocks which is a complicated problem when 
inter-block wirings have to be updated. In case of change in the 
deployment, a global reload will be performed similarily to what is done 
today with the "cocoon-reload" request parameter.

- the container for components within a block (aka "intra-block 
container"): this is where pipeline components will live, along with 
business-logic components. There is no need for classloader shielding 
here, but the need for more J2EE-oriented features like transaction 
management, datasource pooling etc.

For the intra-block container, a good candidate exists today, which is 
quickly becoming a defacto standard because it deserves it: the Spring 
framework. It's more than a container, as it provide a great lot of 
interesting features (as POJOs) helping to quickly develop robust and 
efficient business logic.

For the kernel container, there is no such defacto standard, and adding 
classloader-shielding to Spring is overkill as we only need a very small 
amount of its features. The kernel must be small, efficient and 
rock-solid. Some partial solutions exist today: Pier's Tani which 
provides classloader shielding but not dependency injection, and 
PicoContainer that provides dependency injection but not classloader 
shielding. We have to choose an existing base and augment it to suit our 

Something that has to be taken into account is the existing component 
base: over the years, a number of people have invested in proprietary 
components based on the Avalon APIs. We cannot tell them to trash their 
stuff and rewrite it to use the new Cocoon. So we need some kind of 
legacy support for the Avalon framework APIs so that only minimal update 
is necessary to existing code or even no update at all. Fortunately, 
Spring may allow us to provide this legacy support, through its 
BeanFactory mechanism. A BeanFactory in Spring is responsible for 
creating a component upon request of the container. How this object is 
created is only a concern of the factory. So we could have an 
AvalonBeanFactory that would allow to host Avalon components within a 
Spring container, going through the lifecycle interfaces when a 
component is created and providing a wrapper showing the Spring 
container as a ServiceManager.

Something that has to be decided is if we're to make a revolution or a 
big evolution. IMO, this should be an evolution. The installed base is 
too large to allow use to have something completely different just 
because we want to change component handling. The ServiceManager wrapper 
on top on Spring may be the way to allow the revolution in the core to 
appear like an evolution to the upper-level code, thus allowing a smooth 


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message