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 needs.
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 transition.
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
