cocoon-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [DAISY] Updated: Configuration
Date Thu, 05 Oct 2006 15:50:26 GMT
A document has been updated:

Document ID: 1162
Branch: main
Language: default
Name: Configuration (unchanged)
Document Type: Cocoon Document (unchanged)
Updated on: 10/5/06 3:50:25 PM
Updated by: Carsten Ziegeler

A new version has been created, state: publish


This part has been updated.
Mime type: text/xml (unchanged)
File name:  (unchanged)
Size: 12997 bytes (previous version: 9466 bytes)
Content diff:
+++ <p>Cocoon is a framework consisting of many different components. All these
+++ components are managed by a component container. Starting with Cocoon 2.2 this
+++ container is the <a href="">Spring framework</a>.
+++ So the first step in setting up Cocoon is actually setting up the container and
+++ configuring the Cocoon components in the container.</p>
+++ <p class="note">In previous versions of Cocoon, the container was setup by
+++ Cocoon itself which created a strong dependency between the container and Cocoon
+++ and made integrating Cocoon with other frameworks very difficult.</p>
+++ <p class="note">You can get a skeleton Cocoon application by using the Cocoon
+++ archetypes for Maven 2 - so you don't need to do most of the stuff described
+++ here by hand.</p>
+++ <p>There are various ways to setup a Spring container (have a look at the Spring
+++ documentation), but we suggest to setup a Spring application context using the
+++ context loader listener in your web.xml:</p>
+++ <p><strong>TBD: Show snipped from web.xml</strong></p>
+++ <p>This context listener is invoked by the servlet container on startup of your
+++ web application. By default the configuration for the application context is
+++ read from the file "WEB-INF/applicationContext.xml". This is the place to
+++ configure the Cocoon components:</p>
+++ <p><strong>TBD: Show snipped from applicationContext.xml and explain it</strong>
+++ </p>
    <p>The main goal for the new Cocoon 2.2 configuration system is to avoid
    patching of any provided configuration file (If you're familiar with previous
    versions of Cocoon you might remember the patching of the cocoon.xconf or
(200 equal lines skipped)
    <h1>Shielded Classloading</h1>
--- <p>TBD</p>
+++ <p>Shielded classloading is an optional feature of Cocoon which helps you in
+++ avoiding typical problems with respect to class loading. Usually the servlet
+++ container sets up a class loader for each web application. This class loader
+++ works "parent-first" which means that whenever a class is loaded it is first
+++ searched in the parent class loader of the web application class loader and only
+++ if its not available there, it is loaded from the classes in WEB-INF/classes or
+++ the jars in WEB-INF/lib. In general this is a useful mechanism which also allows
+++ you to share classes between web applications by putting them in the parent
+++ class loader (refer to the documentation of your application server/servlet
+++ engine for more information).</p>
+++ <p>Unfortunately there are some problems with this approach: for example if the
+++ servlet engine has configured a logging framework like commons logging and
+++ exposes thisĀ  in the parent class loader for the web applications, than all web
+++ applications have to use this configuration and are not able to use their own.
+++ Even more important is the used XSLT processor (and some other stuff contained
+++ in the endorsed directory). By default you always use the XSLT processor shipped
+++ with the JDK; you can override this by specifying one using the endorsed
+++ mechanism but in many cases you can't use this way. As the XSLT processor
+++ shipped with the JDK has some bugs it is advisable to use the latest version.
+++ </p>
+++ <p>The only reliable way of avoiding all these class loading issues is to use a
+++ mechanism we call shielded class loading: the web application uses its own class
+++ loader which works "parent-last". In this case classes are always tried to be
+++ loaded from the WEB-INF/classes or WEB-INF/lib directory first. Through this
+++ mechanism you can enforce the use of the XSLT processor you want for your
+++ application, of the logging configuration you need etc.</p>
+++ <p>Some application servers provide a configuration for this, but you can also
+++ use some of the functionality provided by Cocoon: if you are using the Cocoon
+++ deploy plugin with Maven 2, this plugin rewrites your web.xml to use the
+++ shielded class loader.</p>

View raw message