Re: Catalina and log4j
At 23:04 21.04.2001 -0500, you wrote: Ceki Glc wrote: One important point to remember is that each webapp classloader could load a fresh copy of log4j so that each webapp has its own logging universe. This would significantly increase the memory footprint required for logging in the JVM. I would prefer that log4j be global. Right, but it is not our choice to make. The user (i.e. the servlet developer) *can* choose to load a fresh copy per webapp although this is not at all mandatory. It is the users prerogative, a bit like the XML parser I guess. Cheers, Ceki
Re: Catalina and log4j
My two cents as a Log4J User.
I use Log4J in my servlets and I think it great. Logging has never been so easy.
One issue though, the Configurator class holds it data in a Static variable so
two servlets inside the same JVM will each over write the others config. Even
since I implemented Log4J I was worried that my servlets may not play well
with others when trying to deploy at an ISP. Also will you be able to support
one Servlet using a PropertyConfigurastion as opposed to a XMLConfigurator.
A word to the wise, one of our biggest hurdles was where or when to use each
level. i.e. Debug,Info,warn.. It is easy to always use Info or Debug which defeats
the purpose of separate levels. We had to create a standards document that defined
where to implement each. It was surprising how often I need to look at the document
to make the right choice.
Regards
John G
Ceki Glc wrote:
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 Glc
--
--
John Gentilin
Eye Catching Solutions Inc.
18314 Carlwyn Drive
Castro Valley CA 94546
Contact Info
[EMAIL PROTECTED]
Phone 1-510-881-4821
--
Re: Catalina and log4j
At 21:40 21.04.2001 -0700, you wrote: On Sat, 21 Apr 2001, Glenn Nielsen wrote: Ceki Glc wrote: One important point to remember is that each webapp classloader could load a fresh copy of log4j so that each webapp has its own logging universe. This would significantly increase the memory footprint required for logging in the JVM. I would prefer that log4j be global. Log4J is nothing compared to having multiple XML parsers in memory :-) Actually, it is technically feasible to do this either way -- if you put the Log4J JAR file in common/lib instead of server/lib it becomes available to the webapps as well. The disadvantage is that the static variables really are global instead of once per web app (which they would be if each webapp installed its own copy), so they would share the same set of Log4J categories, appenders, and so on. One of the reasons for adding multiple-hierarchy support to log4j was to allow each webapp or virtual host to support logging independently of other webapps or virtual hosts. Given that each webapp has its own classloader AFAIK there is no need to use a custom hierarchy which is significantly more difficult to manage than the default hierarchy. So the support for multiple hierarchies is there but perhaps not needed, at least not for the logging done by the webapps. Ceki
Re: Catalina and log4j
At 20:02 21.04.2001 -0700, you wrote: Since I had so shamelessly copied Craig's Services model out of Catalina to use it in another project that never made it, I actually have some experience with this. I had really appreciated the logging in the Catalina framework, because it was always there, and it was configurable per component. My cohort converted the whole thing to use Log4J in two days, and I was even happier after that. We had started with the retrofitting solution, but it was easier in the end to define a standard way to get the Category, and then cut and paste that code everywhere we needed it. So, I would say go for the whole hog, as it is not very hard ;-) I'd even offer to help ;-) Excellent.
Re: Catalina and log4j
On Sat, 21 Apr 2001, Glenn Nielsen wrote: Ceki, This is welcome news! It isn't clear to me whether the standard servlet API logging methods could use log4j behind the scense to do logging. This would be very nice, especially if you could configure log4j logging for each scope (Engine, Host, DefaultContext, Context) in server.xml. And even configure different destinations for different types of message levels. Whatever logging mechanism is used by org.apache.catalina.core.ApplicationContext *is* the implementation of the servlet API logging methods. Right now, it defers to the Logger of the corresponding Context, but that would be easy to change if we wanted to forcibly separate application-generated messages from Catalina-generated messages. On the other hand, I've found that having the two message streams be intermixed can be useful as well - it would be nice to have it either way. Regards, Glenn Craig
Re: Catalina and log4j
At 17:45 21.04.2001 -0700, you wrote: My two cents as a Log4J User. I use Log4J in my servlets and I think it great. Logging has never been so easy. One issue though, the Configurator class holds it data in a Static variable so two servlets inside the same JVM will each over write the others config. Even since I implemented Log4J I was worried that my servlets may not play well with others when trying to deploy at an ISP. John, As far as I know, the PropertyConfigurator and the DOMConfigurator do not hold any static info. You are free to use them as many times as you want. By default, the log4j configurators act on the default hierarchy although it is possible to specify a custom hierarchy. Having said that, if you configure the same hierarchy multiple times, then each reconfiguration will be merged with the existing configuration. This is known to confuse people but it offers real advantages. If that is not the behavior that you desire, then you can call h.resetConfiguration(), for some hierarchy object h, before reconfiguring. Similarly, use Category.getDefaultHierarchy().resetConfiguration() for resetting the default hierarchy before reconfiguring. Also will you be able to support one Servlet using a PropertyConfigurastion as opposed to a XMLConfigurator. Mixing configurators is not a problem. A word to the wise, one of our biggest hurdles was where or when to use each level. i.e. Debug,Info,warn.. It is easy to always use Info or Debug which defeats the purpose of separate levels. We had to create a standards document that defined where to implement each. It was surprising how often I need to look at the document to make the right choice. Log4j has a rather limited set of priorities specifically to avoid the sort confusion you describe. One of the most important lessons I learned during my formal engineering education was to avoid functionality that could not be clearly understood by a competent audience. My hereto assumption was that DEBUG, INFO, WARN, ERROR and FATAL was the largest set of priorities with no possible confusion. You seem to think otherwise. I would be very interested in peeking at your standards document and perhaps include it in the log4j distribution with your permission of course. TIA, Ceki
Re: Catalina and log4j
Craig R. McClanahan wrote: On Sat, 21 Apr 2001, Glenn Nielsen wrote: Ceki Gülcü wrote: One important point to remember is that each webapp classloader could load a fresh copy of log4j so that each webapp has its own logging universe. This would significantly increase the memory footprint required for logging in the JVM. I would prefer that log4j be global. Log4J is nothing compared to having multiple XML parsers in memory :-) Actually, it is technically feasible to do this either way -- if you put the Log4J JAR file in common/lib instead of server/lib it becomes available to the webapps as well. The disadvantage is that the static variables really are global instead of once per web app (which they would be if each webapp installed its own copy), so they would share the same set of Log4J categories, appenders, and so on. Comments about per webapp vs global installation of jar's: Tomcat 4 defers to the web application ClassLoader first before loading classes from the parent classloaders, as suggested by the Servlet 2.3 spec. Bloating of JVM memory usage due to alot of web applications all having WEB-INF/lib/foo.jar installed could cause a problem with scaling if there are 100's of web applications installed. In our use of Tomcat 4 we will be installing all of the most commonly used taglib jar files and API's in $CATALINA_HOME/lib so they can be shared by multiple web applications. Of course the customer can always override this by installing the jar file locally in WEB-INF/lib, but we will try to encourage them to use the globally installed versions if they can. Ideas for log4j: log4j itself could be installed for Tomcat in $CATALINA_HOME/server/lib. Logging categories, priorities, and destinations could be configured in server.xml scoped at the Engine, Host, DefaultContext, and Context levels. The normal servletAPI log methods would use log4j under the hood. The Tomcat 4 global log4j instance would not be visible to individual web applications. In addition, create a JNDI Factory for log4j so that a logging category for a web application can be exported to it using a JNDI logging resource named something like jndi:/comp/env/log. That resource would only make available to the web application the few methods needed to determine if a logging priority was enabled and to log a message at a priority. This would allow a web application to use log4j without making log4j internals visible to the web application. A manager servlet could even be written to allow changing of log priorities for the web application. And a tag library provided for use in JSP pages. Regards, Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Catalina and log4j
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 Glc
Re: Catalina and log4j
Ceki,
This is welcome news!
It isn't clear to me whether the standard servlet API logging methods could use log4j
behind the scense to do logging. This would be very nice, especially if you could
configure log4j logging for each scope (Engine, Host, DefaultContext, Context) in
server.xml.
And even configure different destinations for different types of message levels.
Regards,
Glenn
Ceki Glc wrote:
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 Glc
--
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
--
