tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Gordon" <adam.gor...@readytalk.com>
Subject RE: Dynamic logging configuration updates in Tomcat
Date Thu, 11 Oct 2007 17:28:16 GMT
Wow, no one had any ideas as to what is going on?

Anyway.  We never figured out why Tomcat has an issue with this, but we
found a suitable workaround by basically doing what the LogHandler does
when it re-reads and refreshes the logging configuration - we take the
new logging level values and apply them to their respective loggers.

In fact, my first test was an exact copy of the LogHandler code and the
test worked (i.e., dynamic logging worked), whereas using the LogHandler
didn't....hmmmm.

--adam

-----Original Message-----
From: Adam Gordon [mailto:adam.gordon@readytalk.com] 
Sent: Tuesday, October 09, 2007 1:55 PM
To: users@tomcat.apache.org
Subject: Dynamic logging configuration updates in Tomcat

Hi-

We have a web application in which we'd like to get dynamic logging 
working.  By dynamic logging, I mean live changes to the webapps' 
logging.properties file are read and applied without having to restart 
Tomcat.  We have all the code written and running but it appears to not 
work exactly as it should.  That is, I can change a logger's logging 
level once and it works, but if I change it again, it doesn't.  If I 
change the global logger level (.level) the change is picked up but, 
obviously, that affects ALL the loggers in our webapp.

I pulled the code out of tomcat and ran it as a stand-alone Java 
application and it works perfectly.  I then created a very tiny/simple 
webapp to run this logging code and the problem appears again.  I'm at a

loss as to what Tomcat can possibly be doing to prevent the properties 
from being read subsequent times after the first change.

We're using the java.util.logging API and have our own LogHandler 
class.  We have a ServletContextListener that starts a background thread

when the webapp starts up.  This background thread finds the 
logging.properties file for this webapp and if it has been modified in 
the last 60 second, creates an InputStream to this file and passes this 
InputStream to the LogManager.getLogManager().readConfiguration(...) 
method.  We are aware of this bug:  
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5035854 in the Java 
logging API, but we are using the workaround in this bug to reapply the 
logging levels.

If we can't find a solution to this using readConfiguration(...), we 
have a solution we've not tried which is to read the properties file 
ourselves, and loop over the loggers applying any levels that have 
changed - which is exactly what the LogManager is doing - but at least 
this is our code.  Again, we've not tried this brute-force method yet, 
so I don't know if it will work.

Thanks,

--adam

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message