log4j-dev is likely the best place for the discussion, just sometime a
discussion never catches fire for some reason. Given your initial
post was in August, vacations are a likely culprit.
How do you propose accessing the FileWatchdog instance to interrupt
it? Looking at DOMConfigurator and PropertyConfigurator, they do not
retain a pointer to the watchdog, so you would need to rely on
Thread.enumerate() or similar and decide which threads that you want
to interrupt.
Also, starting independent threads in a web container is generally
discouraged, so configureAndWatch() is problematic to begin with. In
addition, its semantics are problematic as it incrementally processes
the configuration file (unless you specifically set log4j.reset = true
it just adds the new configuration to the old configuration).
On Aug 15, 2008, at 2:06 AM, Daniel Niklas wrote:
Hi,
nobody with an opinion about this? Shoul'd i move this question to
the users
list?
best regards
Daniel
On Aug 5, 2008, at 5:43 AM, Daniel Niklas wrote:
Hi,
the FileWatchDog daemon can't be interrupted, the
InteruptedException is
ignored. I think, it might be better to accept an interruption -
here stop
observing the File.
I want to use something like DOMConfiguration#configureAndWatch() in
my
webapp. I can't use this, because this would cause many daemon-
threads (of
FileWatchDog). Every restart of my webapp causes a new thread and i
can't
interrupt this thread!
My solution is:
- an interruptable FileWatchDog
- a ServletContextListener
- starts log4j in "contextInitialized"
- shutdown log4j in "contextDestroyed" and interrupts FileWatchDog
What do you think about this?
Best regards
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
