Hi,
Curt Arnold-3 wrote: > > 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. > You're right, the current implementation does't have a reference to the watchdog-thread. Enumerating threads isn't a nice solution. Perhaps the current implementation of configureAndWatch methods can't be used in a web environment. My approach is to start this configuring and watching when the webapp starts and stop it when the webapp stopps. This can be done with a ServletContextListener. Therefor i have to interupt the watchdog-tread, otherwise there would be more than one watchdog-thread. Curt Arnold-3 wrote: > > 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). > I wonder about the semantics of processing the configuration file. I didn't know that! Can i configure a log4j-system with many configuration-files? Does this make sense? Is this relevant for DOMConfiguration, too? Best regards Daniel -- View this message in context: http://www.nabble.com/FileWatchDog-cannot-be-interrupted---missing-support-for-webapps-tp18828607p19045039.html Sent from the Log4j - Dev mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
