You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by bu...@apache.org on 2010/07/08 10:52:43 UTC
DO NOT REPLY [Bug 49571] New: refreshing log4j - reconfigurable from
log4j.properties and safe in J2EE
https://issues.apache.org/bugzilla/show_bug.cgi?id=49571
Summary: refreshing log4j - reconfigurable from
log4j.properties and safe in J2EE
Product: Log4j
Version: 1.2
Platform: PC
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: Configurator
AssignedTo: log4j-dev@logging.apache.org
ReportedBy: tomaszbech@gmail.com
FAQ says:
"Because the configureAndWatch launches a separate wathdog thread, and because
there is no way to stop this thread in log4j 1.2, the configureAndWatch method
is unsafe for use in J2EE envrironments where applications are recycled."
However in HA production J2EE environment it is crucial to have possiblity to
change logging settings (mainly LEVEL) without restarting server.
To simply achieve this:
- add option to configuration file: watchDelay=<miliseconds>
- if watchDelay is declared log4j watches for changes in configuration file.
- skip idea of watchDog and check directly inside calls of logger.debug/info
that there is a need to reload configuration file - by this, it will be 100%
safe in J2EE.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
DO NOT REPLY [Bug 49571] refreshing log4j - reconfigurable from
log4j.properties and safe in J2EE
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49571
Matt Passell <mp...@grovehillsoftware.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mpassell@grovehillsoftware.
| |com
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
DO NOT REPLY [Bug 49571] refreshing log4j - reconfigurable from
log4j.properties and safe in J2EE
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49571
--- Comment #1 from David North <dt...@corefiling.co.uk> 2011-10-06 16:26:08 UTC ---
I've implemented a workaround in my J2EE app which involves subclassing
FileWatchdog and adding a shutdown() method to interrupt its thread at
application undeploy/shutdown.
Since our app already calls LogManager.shutdown() when undeployed (and this
seems like the right thing to do in order to ensure appenders close() methods
etc. are called), I'd favour addressing this bug by making the thread spawned
by configureAndWatch be shut down as part of LogManager.shutdown().
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
DO NOT REPLY [Bug 49571] refreshing log4j - reconfigurable from
log4j.properties and safe in J2EE
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49571
--- Comment #3 from Matt Passell <mp...@grovehillsoftware.com> 2012-01-19 23:42:19 UTC ---
Any new thoughts on this? I'd also like to be able to stop the watchdog thread
as part of LogManager.shutdown(). Newer versions of Tomcat highlight resources
that haven't been cleaned up as a webapp is unloaded and it would be nice to be
able to clean up the watchdog thread. Another issue
(https://issues.apache.org/bugzilla/show_bug.cgi?id=50486) addressed a similar
problem with MDC.clear().
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
DO NOT REPLY [Bug 49571] refreshing log4j - reconfigurable from
log4j.properties and safe in J2EE
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49571
--- Comment #2 from David North <dt...@corefiling.co.uk> 2011-10-06 16:29:35 UTC ---
To expand a little on comment 1 ... the solution proposed in comment 0 would
work, but it seems more risky to victimize a random log.debug/info call to do
the work of checking if the config has changed and reloading it, since this may
unexpectedly slow down whatever part of my app called the logger (and in the
worst case, an exception might be raised as part of doing some logging).
Polling for and applying log4j config changes is exactly the sort of thing a
background thread should be used for; we just need to ensure that log4j makes
an effort to shut down any threads it has started when LogManager.shutdown is
called.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org