Issue warning instead of error when ALLOW_FLAWED_CONTEXT is true and the context

classloader is not related to the classloader used for LogFactoryImpl. This can
happen with JBoss' Unified Classloader approach. See bugzilla#35423.
Thanks to Brian Stansberry for the patch.


git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk@191431 13f79535-47bb-0310-9956-ffa450edef68

src/java/org/apache/commons/logging/impl/LogFactoryImpl.java

@@ -949,11 +949,27 @@ public class LogFactoryImpl extends LogFactory {
                 contextClassLoader, thisClassLoader);
 
         if (baseClassLoader == null) {
+           // The two classloaders are not part of a parent child relationship.
+           // In some classloading setups (e.g. JBoss with its 
+           // UnifiedLoaderRepository) this can still work, so if user hasn't
+           // forbidden it, just return the contextClassLoader.
+           if (allowFlawedContext) {              
+              logDiagnostic(
+                 "Warning: the context classloader is not part of a"
+                 + " parent-child relationship with the classloader that"
+                 + " loaded LogFactoryImpl.");
+              // If contextClassLoader were null, getLowestClassLoader() would
+              // have returned thisClassLoader.  The fact we are here means
+              // contextClassLoader is not null, so we can just return it.
+              return contextClassLoader;
+           }
+           else {
             throw new LogConfigurationException(
                 "Bad classloader hierarchy; LogFactoryImpl was loaded via"
                 + " a classloader that is not related to the current context"
                 + " classloader.");
            }           
+        }
 
         if (baseClassLoader != contextClassLoader) {
             // We really should just use the contextClassLoader as the starting