You are viewing a plain text version of this content. The canonical link for it is here.
Posted to docs@cocoon.apache.org by da...@cocoon.zones.apache.org on 2006/10/06 12:15:33 UTC
[DAISY] Created: Shielded Classloading
A new document has been created.
http://cocoon.zones.apache.org/daisy/documentation/1262.html
Document ID: 1262
Branch: main
Language: default
Name: Shielded Classloading
Document Type: Cocoon Document
Created: 10/6/06 10:15:11 AM
Creator (owner): Reinhard Pötz
State: publish
Parts
=====
Content
-------
Mime type: text/xml
Size: 2182 bytes
Content:
<html>
<body>
<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>
</body>
</html>
Collections
===========
The document belongs to the following collections: cdocs-core