logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <carn...@apache.org>
Subject Re: svn commit: r391905 - in /logging/log4j/trunk: docs/ src/java/org/apache/log4j/ src/java/org/apache/log4j/joran/ src/java/org/apache/log4j/spi/ src/java/org/apache/log4j/watchdog/ src/java/org/apache/log4j/xml/ tests/input/watchdog/ tests/src/java/org/
Date Fri, 07 Apr 2006 06:36:27 GMT

On Apr 7, 2006, at 1:10 AM, Curt Arnold wrote:

> On Apr 6, 2006, at 11:12 PM, Mark Womack wrote:
>> Hm.  That implies that the Watchdog will need to be configured  
>> with what kind of input type to give to the configurator, since  
>> InputSource will not generically work with all configurators (like  
>> PropertyConfigurator).  Or I could add doConfigure(File) to  
>> ConfiguratorEx.  That is probably better.
> I don't see any reason why PropertyConfigurator could not have a  
> doConfigure(InputSource) method.  ConfiguratorEx is a new  
> interface, so there is no compatibility issue.  If a configurator  
> wants to support ConfiguratorEx, it can add a doConfigure 
> (InputSource, LoggerRepository).
>> But another question is what is going to happen when I add  
>> HttpWatchdog and SocketWatchdog this weekend?  How would they  
>> resolve the location of the filespec?  Or would it need to specify  
>> the ENTITY in a different way, maybe as a url?
> An HttpWatchdog (or any watchdog that is representing a resource  
> that can be addressed with a URL) would just call  
> configurator.doConfigure(new InputSource("http://www.example.org/ 
> foo/log4j.xml"), repository) which would provide the base URL for  
> any entities (so in the example the external entity would be  
> resolved as http://www.example.org/foo/stdAppenders.xml).  Don't  
> know about the SocketAppender, I assume that you'd only have a  
> Reader or an InputStream (both of which can be represented in an  
> InputSource).  You couldn't use a configuration file with external  
> entities with relative URL's since there'd be no base URL, however  
> that should be acceptable.  It wouldn't be like the file scenario  
> where it would successfully parse on the initial pass and then  
> start failing on the watchdog.

And forget what I just said about InputSource.  Unfortunately, there  
is not a reliable mechanism to convert File paths to URL on earlier  
JDK's.  You may have to resort to using an approach like I did with  
the DOMConfigurator (in log4j 1.2) and JoranConfigurator where you  
create a distinct object that packages all the necessary  
information.  It may be as simple as having Watchdog take a Runnable  
and invoking run() every time the monitored resource changes. 

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

View raw message