Looking at the resetConfiguration() implementation for Hierarchy (which is where the resetConfiguration method for BasicConfigurator ends up, I think), it does not have any code to deal with Watchdogs. And since references to watchdogs are not stored anywhere, it would have no way to stop them anyway. Watchdogs will still be active after resetConfiguration(). Do you see something specific that maybe I am missing?
-Mark -----Original Message----- From: Michael Wiwchar [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 24, 2002 2:11 PM To: Log4J Users List Subject: Re: Turning of conf file watching Wouldn't the .resetConfiguration method stop the .configureAndWatch methods from working? ----- Original Message ----- From: "Mark Womack" <[EMAIL PROTECTED]> To: "'Log4J Users List'" <[EMAIL PROTECTED]> Sent: Thursday, January 24, 2002 4:47 PM Subject: RE: Turning of conf file watching > Yes, I think you are creating 10 Watchdog threads, all watching the same or > different files, depending on what you pass in as the file to watch. If > they are all watching the same file you won't see any strange behavior on > the surface because they will set up the same configuration each time. But > your code will be doing a lot of extra reconfiguration that it doesn't need > to do. You should turn on log4j debugging (-Dlog4j.debug=true) to watch > what is going on. Maybe I am wrong on this. If the files are different, > the most recently specified/modified file will set the current > configuration. > > Here is the relavant code from PropertyConfigurator.java, > DOMConfigurator.java has something similar: > > static > public > void configureAndWatch(String configFilename, long delay) { > PropertyWatchdog pdog = new PropertyWatchdog(configFilename); > pdog.setDelay(delay); > pdog.start(); > } > > As you can see, it creates a new instance of FileWatchdog and starts it. > There is no provision to stop previously created watchdogs or to even keep > track of them for later termination. I believe the FileWatchdog and > Watchdog classes do not have code to track/terminate the instances either. > > I would write your code to better control when configureAndWatch() is called > or write your own code to implement the behavior you want. The Watchdog > code is not very complicated, and you could create your own version. > Depending on your specific needs, my new proposed version may be what you > need. If not, I'd like to know so I could possibly work it into the > implementation. > > -Mark > > -----Original Message----- > From: Sara Prigge [mailto:[EMAIL PROTECTED]] > Sent: Thursday, January 24, 2002 12:38 PM > To: 'Log4J Users List' > Subject: RE: Turning of conf file watching > > > In my code, I have a method (doLogSetUp) that, among other things, calls the > configureAndWatch method. The doLogSetUp method is called every time a > logging occurs. That means if I need to log 10 times in my application, the > doLogSetUp method is called 10 times, hence the configureAndWatch method is > called 10 times. Are you saying that I would have 10 different threads all > watching my config file? I thought that if I was using the same object each > of the 10 times to call the doLogSetUp method (which calls the > configureAndWatch method)that it would use the same thread (the thread that > was created the first time), rather than create a new one. > > Perhaps my approach is incorrect? It sounds like I should only call the > configureAndWatch method once, say upon a successful user log-in....? > > -----Original Message----- > From: Mark Womack [mailto:[EMAIL PROTECTED]] > Sent: Thursday, January 24, 2002 1:09 PM > To: 'Log4J Users List' > Subject: RE: Turning of conf file watching > > > You can look at the code, but in the current version, there is no mechanism > to stop a Watchdog after it is created and started. In fact, each time you > call configureAndWatch(), it creates a new instance of a Watchdog. So, you > can potentially have multiple Watchdogs watching the same file and stepping > over each other. Unless I am missed something in the code. > > I am working on a some proposed code that will enhance the Watchdog > implementation so that you can have better control over this. The new > design also does not require a configureAndWatch() method in the > configurator class; it will potentially work with any configurator. There > are also more Watchdog types, like one that watches an http url on a web > server. I submitted an initial version to the dev list, and I am working on > updating it to incorporate the first round of feedback. > > If you are interested in looking at it, contact me directly. I would > appreciate the feedback. > > -Mark > > -----Original Message----- > From: Charlie Cano [mailto:[EMAIL PROTECTED]] > Sent: Thursday, January 24, 2002 10:13 AM > To: [EMAIL PROTECTED] > Subject: Turning of conf file watching > > > Hey all, > > Quick question: If I initialize a PropertyConfigurator with > > PropertyConfigurator.configureAndWatch("myConfFile", 1000); > > is there anyway I can turn that watch off? The API doc is not clear on this > issue. I basically want the ability to, at some future point, > programmatically stop checking the configuration file and auto-loading the > configuration. Is this possible? > > Thanks in advance, > Charlie > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
