On Aug 7, 2007, at 2:31 PM, Karan Malhi wrote:
Here is another thought:
The current getInstance method of Logger has the following signature:
Logger getInstance(String name, String baseName)
Logger getInstance(String name, Class clazz)
If one had to obtain a Logger, it is still to easy to do something
like
Logger logger = Logger.getInstance("abc","org.apache.openejb");
i.e. it is still easy to bypass the LogCategory totally. Over time,
this might lead to a problem in that we might again end up in a
situation where we have loggers which are lost in code and are not
defined in log4j.configuration because nobody knows about their
existence. I mean, you can still go and add a Category to LogCategory
and not update log4j configuration, but this way atleast we have
tighter control over where to look for all Categories and then update
log4j if required.
I am thinking to refactor the Logger and LogCategory as below:
Logger getInstance(LogCategory category, String baseName)
Logger getInstance(LogCategory category, Class clazz)
public final class LogCategory {
private String name;
public static final LogCategory OPENEJB = new LogCategory
("OpenEJB");
public static final LogCategory OPENEJB_STARTUP =
new LogCategory (OPENEJB.name + ".startup");
...
...
private LogCategory(String name){ this.name = name;}
public String getName(){return this.name;}
}
What this also gives us is an ability to add methods, for lets say,
generating LogCategories, given a deploymentId (David blevins idea
about loggers with deploymentId as a suffix)
Crazy. I had a similar thought (just using enums) when I posted the
idea about the loggers with app-specific suffixes. I was typing it
up and then the older thought about wanting to have the app's
moduleId in the category came to me and the two seemed mutually
exclusive (at least with enums they would have been).
So I can see some appeal to the idea. I guess if we used old school
enums as you propose we could make it work. We just need some nice
way to create the "sub categories". Maybe we could tuck the creation
of the non static final (the dynamically created) LogCategories away
as in..
// Standard setup part
private static final Logger log = Logger.getInstance
(LogCategory.OPENEJB_DEPLOY, Foo.class);
// Now later i need to do something app specific
Logger appLog = log.getLogger("mySuperApp");
-- - - -- - - - - - -
Under the covers it might just be something like:
return Logger.getInstance(this.logCategory.createChild
("mySuperApp", this.packageName);
I was also thinking about some kind of a "diff" feature, where if a
user wanted, the user could check what Logger Categories are being
used (we can pull them out from the Loggers cache) and what Logger
Categories are defined in the log4j configuration file. The "diff"
feature will simply spit out the Loggers which are not defined in the
log4j configuration file. Since not all Logger Categories need to be
defined in log4j configuration because the level and appenders can be
inherited from parent Loggers, the "diff" tool could be useful in
troubleshooting any logging issues. So where would we put this "diff"
feature? I was thinking , it could be a part of WebAdmin.
We could definitely put something there. I'd have to get the
webadmin working again, but we're pretty close.
-David
