Mailing-List: contact docs-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: docs@cocoon.apache.org
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Apache Wiki <wikidiffs@apache.org>
To: docs@cocoon.apache.org
Date: Wed, 05 Oct 2005 11:04:15 -0000
Message-ID: <20051005110415.18703.18334@ajax.apache.org>
Subject: [Cocoon Wiki] Update of "GT2005HackatonDay1Notes" by ArjeCahn

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:
http://wiki.apache.org/cocoon/GT2005HackatonDay1Notes

------------------------------------------------------------------------------
  = Cocoon 2.2 Internals =
  
- ternals
+ Cocoon internals
  
  Carsten Ziegeler and Reinhart Potz are walking through the new Cocoon 2.2 code.
  
+ 
+ 
- First the Environment/Servlet is setup.
+ First is the Environment/Servlet is setup.
  
  It creates the BootstrapEnvironment.
  After that the CoreUtil is started and it sets up the cocoon core.
@@ -14, +16 @@

  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/cocoon-settings.properties
  
+ 
  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
+ 
  
  BootstrapEnvironment
  CoreUtil
  ServiceManager
  
  
+ 
  Important for cocoon is:
  - the core.
+ 
+ 
  Into debugging mode
  
  Coreutil gets a new Cocoon instance
  
+ 
  For each request, the following objects are created:
  
+ 
-     * Environment
+ Environment
-     * --> Request object
+ --> Request object
-     * --> Response object
+ --> Response object
  
  Cocoon.java
  
+ 
  process method is the main method
  
+ 
  It starts by calling the environment.startingProcessing
+ 
  
  EnvironmentHelper.java
  is an environment helper class
  
+ 
  Then it fires enterProcessor which pushes the environmentinfo on the stack
+ 
  
  You can hook up Request listeners
  
+ 
  Treeprocessor
  
- Sitemap used to be compiled from XSP in 2.0
- In 2.1 Sylvain introduced the treeprocessor
+ In early 2.0 versions, the sitemap used to be compiled to Java using the same engine as XSP
+ But reloading large sitemaps was very slow and 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
  
+ 
+ 
+ For each statement in the sitemap there's a class.
+ 
+ 
- As an example we dive into the GenerateNode
+ As an example we dive into the GenerateNode.java
+ 
  
  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 object
  
+ 
  each processing node has an invoke method. has the sitemap parameters and the pipeline object.
+ then execute the executor that does the work
  
+ 
+ new feature pipeline hints
+ 
+ 
+ Generate is the first one that sets up the pipeline. Get this object van the pipeline selector depending on the type of the attribute.
+ 
+ 
+ and then set on the pipeline the generator.
+ 
+ 
+ Then get current generator from the service manager
+ 
+ 
+ In your component you can get the location of the pipeline
+ 
+ 
+ SerializeNode.java
+ 
+ 
+ Check for either a generator or a reader
+ 
+ 
+ The pipeline is requested from the context. The source, parameters and mimetype is requested. And finally the serializer is set.
+ 
+ 
+ 
+ Each sitemap and subsitemap has an owner: the ServiceManager
+ 
+ 
+ Drawing will be added later. They are created by [JR]
+ 
+ 
+ The sitemap asks the ServiceManager for
+ 
+ a FileGenerator
+ an XSLT Transformer
+ an HTML Serializer
+ etc
+ 
+ Building wil start with creating the serviceManager with the map components/sitemap components.
+ 
+ 
+ In 2.2 we have a classpath for each sitemap.
+ 
+ 
+ ServiceManager gets a classloader from...
+ 
+ When all is setup, it starts the process method of the pipeline
+ 
+ First setup of the generator is called with the parameters specified in the sitemap.
+ 
+ 
+ Finally a serializer is setup as well.
+ 
+ 
+ 
+ The pipeline is setup and each components has all information it needs
+ 
+ Regardless of any Selectors, Matchers etc, the pipeline merely consists of generator, transformer, transformer, transformer, serializer.
+ 
+ 
+ Selectors
+ 
+ 
+ What actually happens with a selector? And actions?
+ 
+ 
+ Processed from top to bottom.
+ 
+ 
+ Sitemap is build once. Actions and selectors are handled directly.
+ 
+ 
+ Why is it not done in SAX?
+ 
+ Pier said:.... 
+ 
+ 
+ Nivo Verwer: Need a picture of the three stages
+ 
+ 
+ Actions are started and finished before processing the content?
+ 
+ 
+ If you have a pipeline using an internal cocoon source two pipelines are build. This happens when the first generator uses the source resolver to fetch the content. So they are not created one after another.
+ 
+ 
+ Three points:
+ 
+ 
+ Read the sitemap and build the graph
+ Walk through the sitemap and assemble components for that specific request.
+ 
+ Then generator.generate();
+ 
+ 
+ 
+ 
+ CachingPipeline
+ 
+ 
+ Components are connected by prev and next, consumer and producer
+ 
+ 
+ XMLTeePipe gets called in the middle to handle caching
+ 
+ 
+ If request is found in the cache it sends 304 (not modified) in the HTTP response.
+ 
+ 
+ The serializer catches all the SAX events generated by the generator.
+ 
+ 
+ Each time the cocoon:// protocol is used it will invoke the buildPipeline function.
+ 
+ 
+ InputModules are called when the component is added to the pipeline. The variableResolver will handle the input modules. So the cocoon pipeline called by an inputModule will be handled before the actual generate is called.
+