One of the main weakness of logging in log4j, and probably other logging frameworks is that, for the most part, the Logger is tied to one dimension, a single name (usually based on the class name).
Most applications and frameworks exist in nice package formats such that a well named package structure can easily allow log4j etc to configure coarse collections of loggers together. Classic example is to set a top-level package-named logger to some level.
This works great, except when a set of classes, while belonging to a specific package hierarchy, also form part of another logical family. Configuring this family means one has to know the logger names of the family and configure them individually and is a bit of a pain.
For example, in a situation where Module Foo is exhibiting a problem in production, we would like to enable DEBUG logging for that module, we can enable the 'com.mycompany.foo' top level logger. However in the case where a problem cuts across modules, say, at the DAO layer, one would have to enable all the DAO classes level loggers to see what might be going on, which is a bit fiddly.
This is the "Domain" concept that has been talked about in the past, and various logger naming hacks have been used to get around this single dimension.
I was thinking of using Annotations to create Domains of Loggers and have some control mechanism made available that works across these in one hit.
Lets say log4j was fully Java 5 enabled. One might be able to do something like:
public class Foo {
...
private static Logger LOG = Logger.getLogger(Foo.class, "myservice",
"mumblefratzlayer", "mymodule");
This would use Java 5 variable arguments to specify the set of Logging Domains this Logger also belongs to. Log4j could then maintain both the hierarchy and Domain list, and ideally expose all of them nicely as individual Logging Domain MBeans. One could then activate DEBUG logging for all Loggers belonging to the "mumblefratzlayer" loggers in one fell swoop. One could also say turn on a complete top-level module logging, but quickly turn off all DAO related Loggers in one hit.
Even with log4j not being Java 5 enabled, I think there could be a backward-compatible mechanism to add this sort of feature. It might have to be a polling mechanism, because the log4j spi does not announce when new Loggers are created. But I think creating a class that:
* polls the log4j Hierarchy.getCurrentLoggers() enumeration* For each Logger name, treat each name as a Class, and lookup Annotation info for the class. If a special annotation is present, read the set of Domains the class belongs to and register them (if not already registered).
One could therefore have, even using log4j 1.2.x, something like this:
...
public @interface LoggingDomain {
String[] domains default {};
}
@LoggingDomain{ domains=myservice", "mumblefratzlayer", "mymodule" }
public class Foo {
...
private static final Logger LOG = Logger.getLogger(Foo.class);
log4j would treat the Foo class as normal, but the compatibility
layer could still observe the Logger being created and register that
class under the Logging Domain registry.
Perhaps this annotation mechanism is even the preferred mechanism, and if Logger.getLogger(Class) method was Annotation aware, it could do the same thing and register that logger with the Domain object.
Anyway, I thought I'd post this for discussion and feedback. We're having a Hackathon next week at Aconex, so one of us might take a crack at this and seeing what it looks like.
Comments appreciated. Paul Smith Core Engineering Manager Aconex The easy way to save time and money on your project 696 Bourke Street, Melbourne, VIC 3000, Australia Tel: +61 3 9240 0200 Fax: +61 3 9240 0299 Email: [EMAIL PROTECTED] www.aconex.comThis email and any attachments are intended solely for the addressee. The contents may be privileged, confidential and/or subject to copyright or other applicable law. No confidentiality or privilege is lost by an erroneous transmission. If you have received this e-mail in error, please let us know by reply e-mail and delete or destroy this mail and all copies. If you are not the intended recipient of this message you must not disseminate, copy or take any action in reliance on it. The sender takes no responsibility for the effect of this message upon the recipient's computer system.
smime.p7s
Description: S/MIME cryptographic signature
