I will make the change later tonight. I don't think we should be making lots of changes to public interfaces like Configurator, but I also don't think we should be permanently hemmed in by them either. Are we recording changes/information anywhere for the 1.3 release? This is one of the things that should be highlighted in the release notes. Is there a file in cvs to update?
My previous implementation did use a thread to watch the socket, and yes, it was possible to kill it so that everything would release. I did not try it in a web app context however, so we will need to test this, obviously. Creating test cases for files and sockets will be easy, but testing http and webapp context will be more challenging. I liked the parallel conversation about embedding Tomcat for use in test cases.
-Mark
----- Original Message ----- From: "Ceki G�lc�" <[EMAIL PROTECTED]>
To: "Log4J Developers List" <[EMAIL PROTECTED]>
Sent: Wednesday, December 08, 2004 5:36 AM
Subject: RE: Adding method to o.a.l.spi.Configurator
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
