Hello,
I am toying with the idea of migrating catalina logging to log4j. Let me begin by
saying that I am far from being familiar with catalina internals but I am getting
there slowly.
After a short initial study and some experimentation, here are some tentative
conclusions:
1) The way logging is done currently in catalina is not optimal or, in plain English,
sucks. Like most project using their own logging API, there are real benefits in using
a more specialized package like log4j instead of the home-brewed solution. More on
this below.
2) Since catalina uses its own class loader, it would be possible to have catalina use
log4j for logging without affecting other parts of Tomcat. This is probably not
entirely true since Tomcat uses a logging hierarchy. I'll ignore this issue for the
time being until I understand the implications. More importantly, existing servelets
using log4j will be unaffected because they will be using a classloader in a different
branch of the cl-tree.
Benefits of the move to log4j would be:
- No more need to do
if(debug > 1)
log("Some message");
instead one would write
log.debug("Some message");
where log is an instance of org.apache.log4j.Category.
- No more need to have a log() method in each catelina class, as in
private static void log(String message) {
System.out.print("Bootstrap: ");
System.out.println(message);
}
in Bootstrap.java. Log4j would use the category name to identify the source of the log
statement.
- Instead of
try {
} catch (IOException e) {
System.out.println("Cannot create URL for " +
filenames[i]);
e.printStackTrace(System.out);
}
one would write
try {
} catch (IOException e) {
log.error("Cannot create URL for " + filenames[i], e);
}
One advantage is that the code becomes shorter. More importantly, the error can be
reported to any defined log4j appender attached to "log" category instance not just to
System.out.
- The user would configure logging in Tomcat using a separate configuration file,
simplifying the actual Tomcat configuration. I am assuming that the DTD for sevlet.xml
is not part of the Servlet spec so it can be modified without fear of contradicting
the spec.
Anyway, I am still studying the problem but it looks pretty encouraging for the
moment. Your comments are welcome. Ceki
--
Ceki Gülcü
