logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Womack <wom...@adobe.com>
Subject RE: Adding method to o.a.l.spi.Configurator
Date Tue, 07 Dec 2004 21:03:43 GMT
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

-----Original Message-----
From: Ceki Gülcü [mailto:ceki@qos.ch] 
Sent: Tuesday, December 07, 2004 12:39 PM
To: Log4J Developers List
Subject: RE: Adding method to o.a.l.spi.Configurator

At 09:14 PM 12/7/2004, you wrote:
>I don't get your comment.  Maybe I did not make myself clear.  Watchdogs
>will not be deriving from the Configurator interface.  They are clients of
>the Configurator interface.  You specify the Configurator class to use, the
>Watchdog creates and instance of that Configurator and then calls the
>doConfigure method on that instance to reconfigure the log4j environment.

Ok, good.

>My point is that for some configuration sources, only having a version of
>doConfigurator that takes a URL is not sufficient.  My example was with
>Socket, but another example might be JMS.

Well, I think JMS is actually a counter example because if I am not
mistaken you can't view a JMS channel as an InputStream. Following
your line of thought we'd need to change the Configurator interface to
support JMS channels.

Coming back to the socket example, how do you see the interaction
between the socket and the watchdog? Will the socket be pushing its data?

>Does that make sense?
>
>-Mark

-- 
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


Mime
View raw message