You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-cvs@jakarta.apache.org by pg...@apache.org on 2001/04/15 09:48:19 UTC
cvs commit: jakarta-log4j/docs TROUBLESHOOT.html
pglezen 01/04/15 00:48:19
Modified: docs TROUBLESHOOT.html
Log:
Added new entry regarding class not found/defined for multiple classloader
environments.
Revision Changes Path
1.5 +53 -1 jakarta-log4j/docs/TROUBLESHOOT.html
Index: TROUBLESHOOT.html
===================================================================
RCS file: /home/cvs/jakarta-log4j/docs/TROUBLESHOOT.html,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- TROUBLESHOOT.html 2001/04/13 00:01:18 1.4
+++ TROUBLESHOOT.html 2001/04/15 07:48:19 1.5
@@ -26,6 +26,8 @@
<li><p><a href=#cce>ClassCastException when instantiating a Category subclasses.</a>
+<li><p><a href=#notfound>My EJB/Servlet/JSP says log4j class not found/defined.</a>
+
</ul>
<hr>
@@ -140,5 +142,55 @@
<p>The <code>DOMConfigurator</code> has a finer grain method for
setting the class of the category object to instantiate.
+<p><a name=notfound><h4>Log4j class not found/defined</h4>
+
+<p>Naturally you should check the classpath. But you should also
+be aware of the presence of multiple classloaders in the JVM:
+<p> <ol>
+<li>the bootstrap classloader
+<li>the extension classloader
+<li>the application classloader
+</ol>
+<p>If you place log4j.jar in the <code>jre/lib/ext</code> directory
+but place user-defined extensions to log4j in the application
+classloader classpath, log4j configurators will not find them.
+
+<p>Servlet, JSP and EJB containers inside of application servers
+usually have their own special classloaders in addition to the
+three mentioned above. While this provides for a greater
+degree of separation for different webapps, EJB containers and the
+application server runtime itself, it can provide headaches to the
+uninitiated.
+
+<p>Classloaders are usually hierarchically related. The bootstrap
+loader forms the root with the extension loader as its child. The
+application loader is the child of the extension loader and it's
+this "app loader" that we use by default when we write standalone
+Java programs.
+
+<p>Upon receiving a class load request, the classloader usually
+delegates it to the parent before attempting to service the request.
+This allows the bootstrap and extension loaders to deliver any classes
+that are part of the JDK or its extensions. Only after this delegation
+fails will the classloader attempt to find the class itself. Note that
+classloaders do not delegate requests to children.
+
+<p>Application servers often use the application loader for its runtime
+classes and create separate classloaders for its webapp and EJB
+containers. These additional classloaders may decend directly
+from the app server's runtime classloader. If log4j is placed in the
+classpath of a webapp classloader, another webapp classloader will not
+necessarily see it. EJBs wouldn't see it either. If log4j is intended
+to be made availble to all objects participating in the app server, it
+should be included in the classpath of a classloader high enough in the
+classloader hierarchy to be seen by all classloaders.
+
+<p>A good article on classloaders with examples using IBM's WebSphere
+application server can be found
+<a href="http://www7.software.ibm.com/vadd-bin/ftpdl?1/vadc/wsdd/pdf/gisell/UnderstandingWebSphereClassLoaders.pdf">here</a>
+in PDF format.
+
+
+
</body>
-</html>
\ No newline at end of file
+</html>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-cvs-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-cvs-help@jakarta.apache.org