tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Kjome <>
Subject Re: Tomcat 5.5.4, Logging and the death of my friend localhost_log
Date Mon, 15 Nov 2004 04:06:19 GMT
At 01:26 AM 11/13/2004 +0100, you wrote:
 >On Fri, 12 Nov 2004 12:53:18 -0600, Jonathan Eric Miller
 ><> wrote:
 >> Actually, I guess the default isn't that bad for UNIX/Linux anyway. In
 >On Windows, I think it's time to start using the .exe wrapper (or
 >another similar wrapper), rather than keep using the .bat scripts,
 >given their current limitations. This redirects output to log files,
 >which are not rotated at the moment (unlike the main procrun logger).
 >I suppose the feature could be added.
 >I know the "new" logging is not perfect, but I think it's better than
 >it was before. As the ServletContext logging is bad, applications were
 >never using it, and logging could not be unified due to Tomcat's use
 >of proprietary loggers. The container logger often has little data,
 >usually uncaught exceptions.

What I liked about the ServletContext logging was that I could dynamically 
create the file using a simple <Logger> in the <Context> element of my 
context configuration file.  This way, all I have to do is the deploy the 
app and the log file is created and rolled for me.  Of course you're right 
that the context logging is weak on its own, but with the 
logging-log4j-sandbox ServletContextLogAppender (see  and ), I can hook in 
application logging to go to the ServletContext log file.  And since that 
file is specified by the server, my own log4j config file need not point at 
any physical location on the machine (and it is my own app's config file, 
not the server's).  The logging will show up wherever the server decides to 
put the servlet context log file for the application.  No more 
context.getRealPath("/WEB-INF/logs") which is not guaranteed to work in all 
cases, nor do I have to configure any directory to point logging to.  Plus, 
I have the full power of Log4j.

This is logging heaven right up to Tomcat-5.0.xx, but with 5.5.x, I lose 
this ability to dynamically define the logger at deployment time.  For each 
context I want logging for, I have to set up an entry in my server-defined 
log4j config file in common/classes (in which case I also have to be the 
server admin) and then deploy the app.  This extra step is a real downgrade 
in functionality and efficiency between 5.0.xx and 5.5.x, IMO.  I'd like to 
see something like the old functionality come back, although I'm not 
holding my breath.

The other thing I'll mention is not so much a bug or defect, but an 
unfortunate collision between log4j's dtd and Tomcat-5.5.x's ServletContext 
logger naming scheme.  for Log4j XML config files, the log4j dtd (used for 
the DOMConfigurator, but not for Log4j-1.3's JoranConfigurator which will, 
hopefully, ameliorate this issue) specifies the <logger> "name" attribute 
as being of Type ID.  As such, the naming scheme Tomcat-5.5.x uses causes a 
parsing failure because it uses characters not allowed in XML ID attributes 
("[", "]", and "/" in <logger 
I'm not in any way implying that this is a bug in Tomcat-5.5.x.  I just 
thought I'd mention it for those who attempt to use Log4j XML config files 
with the DOMConfigurator for servlet context logging.  Using a properties 
file (which, unfortunately, doesn't have all the functionality that an XML 
config file has) or using Log4j-1.3's new JoranConfigurator should get 
around this (although I haven't actually tested this claim as of yet).


 >Rémy Maucherat
 >Developer & Consultant
 >JBoss Group (Europe) SàRL
 >To unsubscribe, e-mail:
 >For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message