commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <>
Subject [Jakarta-commons Wiki] Update of "Logging/StaticLog" by SimonKitching
Date Wed, 08 Mar 2006 01:44:33 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:

The comment on the change is:
Add sections on java.util.logging and on static methods

  fundamental conflict between isolating logging between applications while sharing a static
Log reference,
  and therefore SLF4J faces the same constraints as commons-logging in these scenarios.
+ == Does java.util.logging have this problem? ==
+ Yes. Code using the java.util.logging api can suffer from exactly the issues listed above,
and the
+ recommendation is the same: avoid static references to log objects from code that might
be deployed
+ in a shared classpath.
+ The java1.4 java.util.logging package is an API, allowing multiple implementations of that
+ Java runtimes provide one very simple implementation of the API, but containers such as
J2EE servers
+ typically plug in an alternate more sophisticated implementation.
+ When using the default implementation, the "static" problem doesn't exist because the standard

+ implementation is not container-aware. Of course this has the side-effect of making per-application
+ configuration impossible for the reasons described earlier.
+ When a container provides an implementation that '''is''' container-aware (so that per-application
+ configuration is possible), then exactly the same situation occurs: when code in the shared
+ classpath creates a Log object, it '''must''' be:
+  * initialised with config NOT from any application, or
+  * initialised with config from one of the available applications, or
+  * a proxy that determines the appropriate config each time a method is called
+ As described above, the first gives no per-app config, the second misdirects logging to
+ wrong app when called from a different application, and the third is extremely inefficient.
+ So just as for commons-logging and SLF4J, it is necessary to avoid static Log objects
+ when using java.util.logging unless you '''know''' that the underlying implementation that
+ will be available at runtime is not container-aware.
+ Just to be completely clear: this only applies to code deployed via a classloader that is
+ across multiple "independent" applications. None of this discussion is relevant to 
+ normal application code, or to library code that is never deployed into a shared classpath.
+ These categories of code can safely use static references.
  == Alternatives to static loggers ==
  In most cases, simply leaving out the "static" qualifier from the Log reference is the correct
@@ -153, +186 @@

  Note that this applies only to code that may be deployed in a shared !ClassLoader. Normal
application code
  need not be concerned with this issue at all.
+ == What about static methods? ==
+ When Log objects are not static then logging from static methods presents a particular problem.
+ In general, calling !LogFactory.getLog within the static method is the appropriate solution:
+ {{{
+   public static void doStuff(...) {
+     Log log = LogFactory.getLog("stuff");
+     log.warn(...);
+   }
+ }}}
+ If the static method has a reference to some object that it could retrieve a logger from
it, eg
+ {{{
+   public static void doStuff(AppContext context, ...) {
+     context.getStuffLog().warn("oops");
+   }
+ }}}
+ This doesn't seem widely applicable though. Fancier solutions like retrieving log objects
from a
+ collection in a thread-local variableare probably not worth trying; the !LogFactory.getLog
+ isn't ''that'' slow.
  == Container-assisted logging ==

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message