New in 2.2

While developing Cocoon 2.2 the main goal was simplicity, modularity and consistent configuration. This page is a summary of all the new features and improvements.

General

• Cocoon 2.2 doesn't use an Avalon-based component manager any more but uses Spring 2 instead.
• Cocoon components (sitemap components as well as general components) can be defined as Spring beans now. This brings all the power of Spring (Dependency Injection, AOP framework, etc.) to the core of Cocoon without having to rely on some kind of bridging mechanism. Avalon component configurations are still supported but deprecated.
• Cocoon core has been split up into a bunch of smaller modules (pipeline api/impl, sitemap api/impl, components, etc.). This is an important step in order to make Cocoon more easily embeddable in the future and to define clear contracts.
• An optional additional validation of sitemaps based on an XML schema definition is configureable.
• Cocoon 2.2 uses Comons Logging instead of Avalon Logkit as logging interface and Log4j as logging implementation. (Also see the 'Incompatibles changes' section of this document.)

Modularity

• In order to make Cocoon applications more modular, the Servlet-Service-Framework was introduced. The Servlet-Service-Framework is a general-purpose framework that makes it possible to establish contracts between sub-applications.
• The Servlet-Service-Framework introduces polymorphic relationships between services.
• The Servlet-Service-Framework has no dependency on the 'traditional' Cocoon (sitemap/pipeline machinery) and can be used together with any JavaServlet-compatible web application.

Configuration and Deployment

• Cocoon 2.1 was configured at build time. This means that you have to build Cocoon 2.1 yourself in order to get the Cocoon that you need for your application. There was no simple upgrade path from one minor/patch release to the next. Cocoon 2.2 expands the meaning of blocks. Blocks have become binary deployment units which follow a particular directory structure and can provide Servlet-Services, Java services, Java classes and resources and Cocoon specific files (templates, stylesheets, etc.).
• Cocoon blocks express their dependencies using project object model descriptors (POM 4.0) defined by the Maven project. This makes it easy to build Cocoon 2.2 based projects with Maven 2 though it's no hard requirement.
• Cocoon 2.2 provides a consistent way of configuration based on the Cocoon Spring Configurator - a new Cocoon sub project. It supports the configuration of components based on the Spring property placeholder configurer and the property overrider configurer and is aware of running modes, i.e. you can provide special properties for different environments (e.g. development, test, production).
• Cocoon 2.2 uses Jakarta Commons Logging 1.1 as logging framework and Log4j as default implementation.
• The number of dependencies of a minimal Cocoon application (sitemaps, pipelines, XML templates) was reduced and together they amount to less than 10MB  (incl. Xalan and Xerces libs!).

Tools

• The Cocoon Maven 2 plugin makes is very easy to use Cocoon together with Maven 2 as build system. The main features are
• starting a block as web application (+ support for the automatical reload of Java classes and all other resources),
• rewritting web.xml to weave in a shielding classloader that reverses the classloading hierarchy in order to avoid classloader problems (e.g. with XML libraries),
• a block can supply xpatch files to patch the web.xml of the destination web application.
• Schema files for sitemaps.

Deprecation

• Avalon-style component configurations

Migrating 2.1 components

<beans>
  <bean id="dispatcher" scope="prototype"
    name="org.apache.cocoon.transformation.Transformer/dispatcher"
    class="org.apache.forrest.dispatcher.transformation.DispatcherTransformer">
    <property name="manager" ref="org.apache.avalon.framework.service.ServiceManager"/>
  </bean>
</beans>

Incompatible changes

• All Cocoon components don't implement the Avalon Logkit logging interfaces (org.apache.avalon.framework.logger.Logger ) anymore but Commons logging instead. This change also makes it possible to configure components via Spring configuration files. If you extend one of those components (e.g. AbstractSAXTransformer), you have to change the logger implementation and to recompile your classes. We are sorry but there is no backwards compatible way in doing this move from Avalon Logkit to Commons Logging.