cocoon-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <>
Subject [Cocoon Wiki] Update of "GT2005HackatonDay1Notes" by ArjeCahn
Date Wed, 05 Oct 2005 09:48:03 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Cocoon Wiki" for change notification.

The following page has been changed by ArjeCahn:

New page:
= Cocoon 2.2 Internals =


Carsten Ziegeler and Reinhart Potz are walking through the new Cocoon 2.2 code.

First the Environment/Servlet is setup.

It creates the BootstrapEnvironment.
After that the CoreUtil is started and it sets up the cocoon core.
It instantiates the avalon context and loads all settings.
The core also instanties the avalon component system.
The serviceManager is created. It loads the cocoon.xconf.

The serviceManager is part of the avalon components. It uses the cocoon object. The cocoon
object handles the request processing.

They start talking about the ServletBootstrap environment. It basically creats a wrapper around
the servlet context.

The next thing is creating the coreUtil. It's the core class for setting up cocoon.

After that cocoon is created with the createCocoon function. It sets up the logging system.

Cocoon is created with the new Cocoon object. Then the core is created.

Settings object

The settings object is new in Cocoon 2.2
It stores all directories etc.
Most of them come from web.xml in Cocoon 2.1

Starting with 2.2 it's possible to use propertyfiles
The main one is WEB-INF/

It scans WEB-INF for all properties files

There is also a properties directory from where you can get additional propertie files.

The idea of the settings object is to move away from the avalon context.

The other nice thing of the settings is that it can store every property.

Currently each block can have it's own property file.

For each block there's a properties file

You can set cocoon to use a custom property file as a system property.

CoreUtil object

Daniel suggests to use servlet interfaces instead of our own interfaces

RequestFactory object

The request factory
creates a wrapper around each request.

Is a wrapper around each request to handle fileuploading


Important for cocoon is:
- the core.
Into debugging mode

Coreutil gets a new Cocoon instance

For each request, the following objects are created:

    * Environment
    * --> Request object
    * --> Response object

process method is the main method

It starts by calling the environment.startingProcessing
is an environment helper class

Then it fires enterProcessor which pushes the environmentinfo on the stack

You can hook up Request listeners


Sitemap used to be compiled from XSP in 2.0
In 2.1 Sylvain introduced the treeprocessor

Sylvain will explain something about the tree processor. Rewrite the sitemap engine based
on a navagation tree. Tree of object.
- First step is building the tree
- Second step is execute it.

- Tree processing loadbuilding
- Tree processing node

Build tree of object and goes down the DOM.

Stays alive for the current request. Rebuild after finished all current requests

As an example we dive into the GenerateNode

changeContext is important. Each time we enter the sitemap we change the context.

When you mount a sitemap, we change the context of the sourceresolver.

ConcreteTreeProcessor has a counter of current request. If 0 then dispose the old sitemap

each processing node has an invoke method. has the sitemap parameters and the pipeline object.

View raw message