commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Jakarta-commons Wiki] Update of "Logging/FrequentlyAskedQuestions" by SimonKitching
Date Fri, 06 May 2005 12:18:55 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jakarta-commons Wiki" for change notification.

The following page has been changed by SimonKitching:
http://wiki.apache.org/jakarta-commons/Logging/FrequentlyAskedQuestions

The comment on the change is:
Changed comments related to "Log4JLogger does not implement Log" message.

------------------------------------------------------------------------------
  What's the cause and how can I fix this problem?
  }}}
  
- This almost always a classloader issue. Log has been loaded by a different classloader
- from Log4JLogger. Please ensure that:
+ It's due to classloaders. The error message should really read something like
+ {{{
+   org.apache.commons.logging.impl.Log4JLogger loaded via classloader XXXXX
+   is bound to interface org.apache.logging.impl.Log as loaded via classloader XXXXX
+   but is required to bind to org.apache.logging.impl.Log as loaded by classloader YYYYY.
+ }}}
  
-  * all the logging classes (both Log and the logging implementations) are deployed by the
same classloader
+ If you get this problem, __please__ post to the commons-user list. We would love to hear
from you so that we can ask you to 
+ run some simple diagnostic code. We really need more detailed information on this issue,
including things like
+  * what is the classloader hierarchy
+  * whether parent-first or parent-last (aka child-first) classloading is selected
+  * exactly which classloader has ended up loading which logging-related classes
+ 
+ There are some things you can try to resolve this issue. Ensure that:
+  * All the logging classes (both Log and the logging implementations) are deployed by the
same classloader. In other words, place commons-logging.jar and the logging library jar in
the same directory.
-  * there is only copy of the classes to be found within the classloader hierarchy. In application
container environments this means ensuring that if the classes are found in a parent classloader,
they are not also present  in the leaf classloader associated with the application. So, if
the jar is deployed within the root classloader of the container then it should be removed
from the application's library.
+  * There is only copy of the classes to be found within the classloader hierarchy. In application
container environments this means ensuring that if the classes are found in a parent classloader,
they are not also present in the leaf classloader associated with the application. So, if
the jar is deployed within the root classloader of the container then it should be removed
from the application's library.
  
  == How Can I Use Commons-Logging In WebSphere 5.1? ==
  
@@ -37, +48 @@

  I'm using WebSphere 5.1. Commons-Logging doesn't seem to recognize my commons-logging.properties
file. Help!
  }}}
  
- Web Sphere uses commons-logging and so it's in the root classloader. This may cause difficulties
when trying to find a configuration resource. The solution is to ensure that the right classloader
policy is set:
+ WebSphere uses commons-logging and so it's in the root classloader. This may cause difficulties
when trying to find a configuration resource. The solution is to ensure that the right classloader
policy is set:
  
  {{{
  Set EAR classloader mode as PARENT_LAST and WAR classloader policy as Application

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message