logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Womack" <mwom...@apache.org>
Subject Re: Adding method to o.a.l.spi.Configurator
Date Wed, 08 Dec 2004 16:18:47 GMT
I think most users will just file and http, but I don't want to prevent them 
from using other sources as well.  I have thought about socket and JMS, but 
I'm sure someone will come up with something very novel here.

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 

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.


----- Original Message ----- 
From: "Ceki Gülcü" <ceki@qos.ch>
To: "Log4J Developers List" <log4j-dev@logging.apache.org>
Sent: Wednesday, December 08, 2004 5:36 AM
Subject: RE: Adding method to o.a.l.spi.Configurator


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 
>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 
>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
><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 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 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"/>
>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).

Ceki Gülcü

  The complete log4j manual:  http://qos.ch/log4j/

To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message