[Jakarta-commons Wiki] Update of "Logging/FrequentlyAskedQuestions" by SimonKitching
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: Minor tweaks -- == When should I use commons-logging? == - Commons-logging is very important when writing libraries that might be used in other projects. If the + Commons-logging is very important when writing '''libraries''' that might be used in other projects. If the - library codes directly to a concrete logging library (eg log4j or java.util.logging) but the application + library directly calls a concrete logging library API (eg log4j or java.util.logging) but the application it is embedded in is using some other logging library then there is a problem. However if the library is using - commons-logging then commons-logging just auto-detects what real logging lib is used in the - surrounding application and adapts to it (or manual config can be used to override the auto-detection) - so that the libraries' output and the application's output is all nicely unified. + commons-logging then commons-logging simply forwards all calls to whatever logging library the surrounding + application is using, ensuring output is all nicely unified. The specific underlying library commons-logging uses can be + explicitly configured (recommended), or commons-logging can be permitted to auto-detect it. - Commons-logging can be useful when you are writing an application but want to allow the person installing + Commons-logging can also be useful when you are writing an '''application''' but want to allow the person installing your app to choose what logging lib to use. Apache Tomcat does this; the person installing it can choose to use log4j, java.util.logging, etc. There is some debate over how useful this actually is. - Commons-logging can also be useful when you are writing an application but want to reserve the right to + Commons-logging can also be useful when you are writing an '''application''' but want to reserve the right to swap logging libraries at a later date. This is not so important, though, as it really isn't that hard to use some refactoring tool or a few scripts to change source code from using library X to library Y. @@ -63, +63 @@ == How Do I Change The Logging System Configuration? == The configuration supported by JCL is limited to choosing the underlying logging system. JCL does not (and will never) support changing the configuration of the wrapped logging system. Please use the mechanisms provided by the underlying logging system. + + The only exception is when using the !SimpleLog logging facility built into commons-logging. In this case, see the documentation for that class + for details on configuring logging levels. == Should I declare Log references static or not? == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta-commons Wiki] Update of "Logging/FrequentlyAskedQuestions" by SimonKitching
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:
Add known issue re Tomcat Jspc and Ant
--
* 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 one 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.
+ === Known causes of "does not implement Log" ===
+
+ Running JspC from Ant
+
+ The Tomcat JspC tool compiles JSP pages into bytecode. It had a bug in
versions prior to 5.5.5 or 5.0.30. where
+ it set the context classloader to a non-standard value, then failed to reset
it to the original value
+ on exit. When run "in-process" as an ant task this would cause
commons-logging to try to load logging libraries
+ from an invalid classloader. This bug has been fixed in the 5.5.5 and 5.0.30
releases of Tomcat.
+
== How Can I Use Commons-Logging In WebSphere 5.1? ==
{{{
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta-commons Wiki] Update of "Logging/FrequentlyAskedQuestions" by SimonKitching
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: Add link to new page about static Log references -- == How Do I Change The Logging System Configuration? == The configuration supported by JCL is limited to choosing the underlying logging system. JCL does not (and will never) support changing the configuration of the wrapped logging system. Please use the mechanisms provided by the underlying logging system. + + == Should I declare Log references static or not? == + + Short answer: static references to Log instances are ok for application code, but a bad idea for library code. + + See this page for details: + http://wiki.apache.org/jakarta-commons/Logging/StaticLog == Log4JLogger does not implement Log == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta-commons Wiki] Update of "Logging/FrequentlyAskedQuestions" by SimonKitching
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: Moved FAQ info in static webpages to wiki -- The JULI module in Apache Tomcat provides adapters from the java.util.logging API log4j. This is of course not an option for code that may be run in JVMs prior to 1.4. The java.util.logging system can also be awkward to set up. + + + == Is JCL Thread Safe? == + + JCL doesn't (and cannot) impose any requirement on thread safety on the underlying implementation and thus its SPI contract doesn't guarantee thread safety. However, JCL can be safely used in a multi-threaded environment as long as the underlying implementation is thread-safe. + + It would be very unusual for a logging system to be thread unsafe. Certainly, JCL is thread safe when used with the distributed Log implementations. + + == How Can I Switch Logging Levels On And Off? == + + See How Do I Change The Logging System Configuration? + + == How Do I Change The Logging System Configuration? == + + The configuration supported by JCL is limited to choosing the underlying logging system. JCL does not (and will never) support changing the configuration of the wrapped logging system. Please use the mechanisms provided by the underlying logging system. == Log4JLogger does not implement Log == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta-commons Wiki] Update of "Logging/FrequentlyAskedQuestions" by SimonKitching
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: Added info about java.beans.Introspector -- ClassLoader contextClassLoader = Thread.currentThread().getContextClassLoader(); LogFactory.release(contextClassLoader); - // optionally, clean up the underlying concrete logging library too + // Optionally, clean up the underlying concrete logging library too. This might + // require direct calls to methods on library-specific methods. + + // And optionally call java.beans.Introspector.flushCaches if your app does any + // bean introspection and your container doesn't flush the caches for you on + // servlet undeploy. Note that this isn't a commons-logging problem; it's something + // quite unrelated which can also cause memory leaks on undeploy. } } }}} The deployment descriptor for the webapp then needs to be updated to specify that the above class should receive context change callbacks. - You can find more information on this topic [wiki:Self:Logging/UndeployMemoryLeak here] + You can find more information on this topic [wiki:Self:Logging/UndeployMemoryLeak here]. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta-commons Wiki] Update of "Logging/FrequentlyAskedQuestions" by SimonKitching
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: Added sections on "when should I use commons-logging" and "alternatives" -- Space for questions and answers. Note that the user mailing list is usually the best place to get answers to question. Remember to search the archives! If someone on the mailing lists has answered your question, why not save everyone else a lot of trouble by recording the answer here :) + + == When should I use commons-logging? == + + Commons-logging is very important when writing libraries that might be used in other projects. If the + library codes directly to a concrete logging library (eg log4j or java.util.logging) but the application + it is embedded in is using some other logging library then there is a problem. However if the library is using + commons-logging then commons-logging just auto-detects what real logging lib is used in the + surrounding application and adapts to it (or manual config can be used to override the auto-detection) + so that the libraries' output and the application's output is all nicely unified. + + Commons-logging can be useful when you are writing an application but want to allow the person installing + your app to choose what logging lib to use. Apache Tomcat does this; the person installing it can choose to + use log4j, java.util.logging, etc. There is some debate over how useful this actually is. + + Commons-logging can also be useful when you are writing an application but want to reserve the right to + swap logging libraries at a later date. This is not so important, though, as it really isn't that hard to use + some refactoring tool or a few scripts to change source code from using library X to library Y. == What Java versions are supported? == @@ -17, +34 @@ If you encounter difficulties using commons-logging on specific java versions, please post to the commons-user list so the problem can be addressed and/or this FAQ entry updated. + + == What alternatives are there to commons-logging? == + + The SLF4J project has similar goals to commons-logging. It uses quite a different approach, however, which has both + benefits and drawbacks. Future versions of commons-logging may adopt some of the concepts of SLF4J. + See http://slf4j.org for more details. + + The Avalon !LogKit provides adapters to other logging libraries. However this library is not very widely used and + is not (as far as I know) maintained any longer. + + The JULI module in Apache Tomcat provides adapters from the java.util.logging API log4j. This is of course not an option for + code that may be run in JVMs prior to 1.4. The java.util.logging system can also be awkward to set up. == Log4JLogger does not implement Log == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta-commons Wiki] Update of "Logging/FrequentlyAskedQuestions" by SimonKitching
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: Added link to new UndeployMemoryLeak page -- The deployment descriptor for the webapp then needs to be updated to specify that the above class should receive context change callbacks. + You can find more information on this topic [wiki:Self:Logging/UndeployMemoryLeak here] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta-commons Wiki] Update of "Logging/FrequentlyAskedQuestions" by SimonKitching
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:
Added info about fixing memory leaks on webapp undeploy
--
"getLogger" method that returns the real underlying object. However in most
cases this is not necessary, as initialisation/shutdown
methods need to be invoked on "the logging library as a whole" rather than
the objects representing individual logging categories.
+ == A memory leak occurs when undeploying/redeploying a webapp that uses
Commons Logging. How do I fix this? ==
+
+ When commons-logging is deployed in a "shared" classloader that is visible to
all webapps, commons-logging still ensures that each
+ webapp gets its own logging configuration by setting up a separate
!LogFactory object for each context classloader, and ensuring that
+ the correct !LogFactory object is used based on the context classloader set
whenever !LogFactory.getLog is called.
+
+ However the negative side of this is that !LogFactory needs to keep a static
map of !LogFactory objects keyed by context classloader;
+ when the webapp is "undeployed" this means there is still a reference to the
undeployed classloader preventing the memory used by
+ all its classes from being reclaimed.
+
+ The commons-logging-optional.jar optional code provided with commons-logging
1.0.4 attempted to address this issue using weak references,
+ but this approach cannot solve the issue in many cases.
+
+ The correct solution in the case of a webapp is for the webapp to include a
class which implements !ServletContextListener:
+
+ {{{
+ class ContextManager implements javax.servlet.ServletContextListener {
+ public void contextDestroyed(ServletContextEvent sce) {
+ ClassLoader contextClassLoader =
Thread.currentThread().getContextClassLoader();
+ LogFactory.release(contextClassLoader);
+
+ // optionally, clean up the underlying concrete logging library too
+ }
+ }
+ }}}
+
+ The deployment descriptor for the webapp then needs to be updated to specify
that the above class should receive context change callbacks.
+
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta-commons Wiki] Update of "Logging/FrequentlyAskedQuestions" by SimonKitching
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 X
+ is bound to interface org.apache.logging.impl.Log as loaded via classloader
X
+ but is required to bind to org.apache.logging.impl.Log as loaded by
classloader Y.
+ }}}
- * 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta-commons Wiki] Update of "Logging/FrequentlyAskedQuestions" by SimonKitching
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: info on jvm versions supported by commons-logging -- Space for questions and answers. Note that the user mailing list is usually the best place to get answers to question. Remember to search the archives! If someone on the mailing lists has answered your question, why not save everyone else a lot of trouble by recording the answer here :) + + == What Java versions are supported? == + + Commons-logging versions 1.0.2 through 1.0.4 require java 1.2. Work is currently in progress on the successor to 1.0.4, and thought is being + given to restoring support for java version 1.1 - it is not currently known whether this is possible. + + Commons-logging version 1.0.1 is believed to work with java 1.1, but only in Applets. To be more specific, commons-logging 1.0.1 + is believed to fail on java 1.1 when the commons-logging classes are loaded by the system classloader; this ''is'' the case for + normal applications, but not the case for Applets. + + If you encounter difficulties using commons-logging on specific java versions, please post to the commons-user list so the + problem can be addressed and/or this FAQ entry updated. == Log4JLogger does not implement Log == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta-commons Wiki] Update of "Logging/FrequentlyAskedQuestions" by SimonKitching
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: minor clarifications on logging init/termination -- In particular, it is intended to allow library code to contain logging calls without caring about what concrete log implementation is being used by the wider application the library is deployed within. - It is not intended to isolate applications from the logging-specific details of initialization and termination. + It is not intended to isolate applications from the logging-library-specific details of initialization and termination. The fact that some logging implementations auto-configure themselves when first used doesn't mean that commons-logging guarantees to do this in all cases, nor that the default initialization behaviour of the concrete logging libraries is appropriate under all circumstances. @@ -53, +53 @@ all libraries will work correctly in this manner, nor that commons-logging will isolate code from this task. In short: when necessary, obtain a reference to the actual underlying log implementation and use library-specific calls to initialise - and terminate as required. + and terminate as required. Yes this means that at least one part of your code will need to know what actual logging library is being + used, and reference classes from that actual logging library to do the appropriate initialisation/shutdown. If you need a reference to the underlying object for a particular commons-logging Log object in order to perform initialisation or termination, then in most cases the org.apache.commons.logging.Log class can be downcast to a concrete type that then has a - "getLogger" method that returns the real underlying object. + "getLogger" method that returns the real underlying object. However in most cases this is not necessary, as initialisation/shutdown + methods need to be invoked on "the logging library as a whole" rather than the objects representing individual logging categories. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
