From a5b7839fec53339658ef2753372fd0cd62d29fb8 Mon Sep 17 00:00:00 2001 From: Robert Burrell Donkin Date: Sat, 11 Mar 2006 10:22:36 +0000 Subject: [PATCH] Added contents section. Improved readability of custom implementation prose. Speiling fixes. Thanks to Simon Kitching for spotting incongruent grammar by I. git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk@385047 13f79535-47bb-0310-9956-ffa450edef68 --- xdocs/troubleshooting.xml | 30 ++++++++++++++++++++++++------ 1 file changed, 24 insertions(+), 6 deletions(-) diff --git a/xdocs/troubleshooting.xml b/xdocs/troubleshooting.xml index fd4a161..9f6ca59 100644 --- a/xdocs/troubleshooting.xml +++ b/xdocs/troubleshooting.xml @@ -26,6 +26,12 @@ +
+ +

Diagnostics is a feature introduced in JCL 1.1 as an aid to debugging problems @@ -210,15 +216,15 @@ classloader used to load LogFactory and to the TCCL.

Some containers use a custom LogFactory implementation to adapt JCL to their particular - logging system. This has some important consequences for deploying applications using JCL within these - containers. + logging system. This has some important consequences for the deployment of applications using JCL within + these containers.

Containers known to use this mechanism:

Containers suspected to use this mechanism: @@ -226,7 +232,12 @@ classloader used to load LogFactory and to the TCCL.

+
  • WebSphere Application Server (other versions).
    • + +

    +The Jakarta Commons team would be grateful if reports were posted to the development list +of other containers using a custom implementation. +

    @@ -276,7 +287,9 @@ The policy adopted by JCL in this situation is to re-throw this exception. Addit is included in the message to help diagnosis. The reasoning behind this choice is that a particular LogFactory implementation has been actively specified and this choice should not be ignored. This policy has unfortunate consequences when running in -containers which have custom implementations: the above runtime exception will be thrown. +containers which have custom implementations: the above runtime exception may be thrown +under certain classloading policies without the user knowingly specifying a custom +implementation.

    @@ -284,8 +297,13 @@ containers which have custom implementations: the above runtime exception will b There are various ways to fix this problem. Which fix is right depends on the circumstances.

    + If you are happy using another classloading policy for the application, select a + classloading policy which ensures that LogFactory will be loaded from the + shared classloader containing the custom implementation. +

    +

    If you want to bypass the container adaption mechanism then set the appropriate system property - to it's default value when the container is started: + to the default value when the container is started: 

      -Dorg.apache.commons.logging.LogFactory=org.apache.commons.logging.impl.LogFactoryImpl