Mark,
IMHO, watching files and urls (including http://) covers most needs whereas watching sockets is a non-essential feature. As intimated previously, I am not extremely thrilled with changing the Configurator interface. However, if you think an additional method would help, then so be it.
My previous question about the socket and its interaction with the watchdog was really about the way the Socket watchdog would acquire new configuration data. If I recall correctly, your previous implementation of SocketWatchdog would listen on a socket and wait for clients to push new config data. However, this requires SocketWatchdog to have its own thread to listen on. As long as this thread can be made to stop when LogManager.shutdown() or repository.shutdown() is called, then I have no objections. Otherwise, if the thread will just hang there and prevent correct application recycling, then we would have a serious bug on our hands.
As usual, I'd be glad to see test cases accompanying this new important contribution.
At 10:03 PM 12/7/2004, Mark Womack wrote:
In the JMS case, it does not support InputStream, but one can do some work to cast/wrap the data as an InputStream (in the watchdog), where I cannot cast/wrap it as a URL very easily, if at all.
In the Socket case, yes, data would be pushed to the watchdog watching the socket. I do not have my specific implementation in front of me. The format of the data being pushed would need to match what the configurator is expecting.
It is not hard to imagine having multiple remote servers with watchdogs pointed to a single Socket or JMS topic and having a tool to push new/updated configuration to all of the remote servers simultaneously via that medium.
Now, I want to point out that I worked around this limitation before. I had some code that used reflection/introspection to examine the configurator class to make sure it had a compatible version of doConfigure using InputStream before calling it. However, it was messy, and easily allowed for the creation of configurators that would not be compatible with all watchdog sources going forward. Watchdogs are going to open some avenues here and I think Configurator should be updated so that it does not hinder those directions. I still argue (from our previous discussion many moons ago), that InputStream is a lower common denominator than URL, and that Configurators should support them.
Using your Joran example, some watchdog examples might look something like this:
<watchdog class="org.apache.log4j.watchdog.FileWatchdog"> <param name="configuratorClass" value="org.apache.log4j.joran.JoranConfigurator"/> <param name="url" value="file://home/myconfig.xml"/> <param name="interval" value="60s"/> <param name="resetOnChange" value="true"/> </watchdog>:
<watchdog class="org.apache.log4j.watchdog.HttpWatchdog"> <param name="configuratorClass" value="org.apache.log4j.joran.JoranConfigurator"/> <param name="url" value="http://myhost/config/myconfig.xml"/> <param name="interval" value="60s"/> <param name="resetOnChange" value="true"/> </watchdog>
<watchdog class="org.apache.log4j.watchdog.SocketWatchdog"> <param name="configuratorClass" value="org.apache.log4j.joran.JoranConfigurator"/> <param name="host" value="localhost"/> <param name="port" value="8081"/> <param name="resetOnChange" value="true"/> </watchdog>
You can easily change the configuratorClass to something else. The only requirement is that the watched source must then provide the configuration data in the format expected by the configurator (ie xml, properties, etc).
-Mark
-- Ceki G�lc�
The complete log4j manual: http://qos.ch/log4j/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
