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/StaticLog 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 API. + 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 log + 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 the + 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 shared + 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 solution. @@ -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 method + isn't ''that'' slow. == Container-assisted logging == --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
