You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Adam Gordon <ad...@readytalk.com> on 2007/10/09 21:55:23 UTC
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
Re: Dynamic logging configuration updates in Tomcat
Posted by Carl Mosca <ca...@gmail.com>.
> I've never heard of embedded Tomcat. That said, the whole deal w/
> embedded systems is that the API is drastically limited so if logging
> isn't working, and this may sound like a dumb question but, is it
> possible that logging just isn't supported?
Yes, it's possible but not probable based on what I have read and the
responses to my questions late last week.
The webapps contain some generated code which does contain a few
System.out.println's along with logging.
I am getting the std out but I would think the logging would at least go to
the default/configured logging.
I get logging from the "hosting" app just fine and the web apps logging
output is OK when running standalone Tomcat.
Regardless, space isn't really an issue for us in that this webapp is on
> it's own production quality server....unless there's a totally logical
> reason to use an embedded Tomcat instance.
Not an issue here either; this is more of an end-user convenience issue (the
server app along with the hosted web apps are launched/updated via Java Web
Start).
Re: Dynamic logging configuration updates in Tomcat
Posted by Adam Gordon <ad...@readytalk.com>.
I've never heard of embedded Tomcat. That said, the whole deal w/
embedded systems is that the API is drastically limited so if logging
isn't working, and this may sound like a dumb question but, is it
possible that logging just isn't supported?
Regardless, space isn't really an issue for us in that this webapp is on
it's own production quality server....unless there's a totally logical
reason to use an embedded Tomcat instance.
--adam
Carl Mosca wrote:
> Adam,
>
> Have you tried your code with the embedded Tomcat?
>
> (I am not having any success getting a webapp to do logging within embedded
> Tomcat.)
>
> TIA,
> Carl
>
>
---------------------------------------------------------------------
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
Re: Dynamic logging configuration updates in Tomcat
Posted by Carl Mosca <ca...@gmail.com>.
Adam,
Have you tried your code with the embedded Tomcat?
(I am not having any success getting a webapp to do logging within embedded
Tomcat.)
TIA,
Carl
RE: Dynamic logging configuration updates in Tomcat
Posted by Adam Gordon <ad...@readytalk.com>.
> I have no idea if Tomcat supports this -- the logging-related
> configuration directives in the docs should say if it is directly
> supported.
I didn't see anything in the logging documentation that's indicated
either way whether or not this was supported. The JVM theoretically
supports it with the LogManager.readConfiguration(...) method but as I
originally noted, there's a known bug in the JVM that causes new
configurations to not be loaded, however there is a work-around.
> Where do you do this? In your webapp or somewhere else?
We already have several servlet context listeners, so in the one that
initializes the web app (database, initializes static classes, etc...)
we add a thread to our thread pool whose sole job is to read the
logging.properties file and if it's changed within the last minute apply
those changes. Originally, we constructed an InputStream from this file
and passed the stream to LogManager.readConfiguration(...) but as I've
mentioned (and even with the bug work-around) this only works for the
first couple of log file changes. After the first few changes, it stops
working entirely in that no subsequent changes to the logging.properties
file is picked up short of changing the .level log level property.
> If you come up with something, consider logging a bug/enhancement and
> submitting a patch. Suggestions with patches are usually given higher
> priority than those without patches ;)
I'd love to submit a patch, only I never found out where in Tomcat (if
it's even IN Tomcat) the problem is occurring. My first test was
copying verbatim the code from LogManager that reads the properties from
the InputStream and iterates over the logging level properties applying
them to their respective loggers. It worked consistently when I copied
it over, but not when I relied on LogManager to do it. Once I got it
working consistently, I tweaked the code a little to maintain a mapping
of logger names to log levels so I could reset log levels for loggers
who had been removed from the logging.properties file during subsequent
changes.
--adam
-----Original Message-----
From: Christopher Schultz [mailto:chris@christopherschultz.net]
Sent: Thursday, October 11, 2007 12:39 PM
To: Tomcat Users List
Subject: Re: Dynamic logging configuration updates in Tomcat
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Adam,
Adam Gordon wrote:
> Wow, no one had any ideas as to what is going on?
I have no idea if Tomcat supports this -- the logging-related
configuration directives in the docs should say if it is directly
supported.
If you're using log4j, I know that there are tools you can use to modify
the in-memory configuration of the logging framework, but they won't be
persisted to the disk (and they don't allow you re-read the
configuration file AFAIK).
> 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.
Where do you do this? In your webapp or somewhere else?
> 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.
If you come up with something, consider logging a bug/enhancement and
submitting a patch. Suggestions with patches are usually given higher
priority than those without patches ;)
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHDm2x9CaO5/Lv0PARAhWXAJ4nVi21oqN7A99wtoZMtY1HzfUQNwCcDR8Q
ivOydqjYdN1xGwtd1WqrU8c=
=4Bp9
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
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
Re: Dynamic logging configuration updates in Tomcat
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Adam,
Adam Gordon wrote:
> Wow, no one had any ideas as to what is going on?
I have no idea if Tomcat supports this -- the logging-related
configuration directives in the docs should say if it is directly supported.
If you're using log4j, I know that there are tools you can use to modify
the in-memory configuration of the logging framework, but they won't be
persisted to the disk (and they don't allow you re-read the
configuration file AFAIK).
> 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.
Where do you do this? In your webapp or somewhere else?
> 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.
If you come up with something, consider logging a bug/enhancement and
submitting a patch. Suggestions with patches are usually given higher
priority than those without patches ;)
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHDm2x9CaO5/Lv0PARAhWXAJ4nVi21oqN7A99wtoZMtY1HzfUQNwCcDR8Q
ivOydqjYdN1xGwtd1WqrU8c=
=4Bp9
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
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
RE: Dynamic logging configuration updates in Tomcat
Posted by Adam Gordon <ad...@readytalk.com>.
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