I'm on the log4j team. We need to add a way for folks to know DOMConfigurator.configure failed (to support configureAndWatch, we probably need to have the notification via a callback)..
I'll file a bug. Slightly off topic: Qpid-dev folks might find Log4j's Chainsaw log analysis UI helpful in searching/filtering and sorting logs... It's available as a download or via Web Start here: http://logging.apache.org/chainsaw/index.html Chainsaw can parse regular text-based log files, load XML-based log files (conforming to java.util.logging format or log4j's format) and receive events via socket (TCP, UDP and multicast). It can even tail log files accessible via ssh. There's an example receiver configuration available from the 'Welcome' tab of Chainsaw, and a tutorial from the help menu. To tail regular text log files, use LogFilePatternReceiver (you can set it up from the GUI or through the xml configuration). To tail regular log files over SSH, use VFSLogFilePatternReceiver instead. Would love feedback or suggestions (and yes, you can change the colors for the different severity levels). If folks have questions, let me know. Scott -----Original Message----- From: Senaka Fernando [mailto:[EMAIL PROTECTED] Sent: Monday, May 19, 2008 2:50 PM To: [email protected] Subject: Re: Question on Log Configuration Watcher in Java Broker Hi Robert, After carefully reading through the log4j implementation, I tried reverting and repeating the error and I discovered that log4j internally handles this situation. But, it rather does not log that it recovered. Which lead to an incorrect assumption that polling has stopped. I'm taking a look at the possibility of logging a debug message, or contacting the log4j team regarding this matter. And, as you say modifying log4j would be much simpler. Also, the choice made at startup is better than what we expected. The log4j system logs this, and the broker continues to be in operation. log4j:WARN Fatal parsing error 49 and column 7 log4j:WARN The element type "log4j:configuration" must be terminated by the matching end-tag "</log4j:configuration>". log4j:ERROR Could not parse file [/home/senaka/qpid/java/distribution/target/qpid-1.0-incubating-M3-SNAPS HOT/etc/log4j.xml]. org.xml.sax.SAXParseException: The element type "log4j:configuration" must be terminated by the matching end-tag "</log4j:configuration>". at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.jav a:239) at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(Docume ntBuilderImpl.java:283) at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:208) at org.apache.log4j.xml.DOMConfigurator$1.parse(DOMConfigurator.java:598) at org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:71 1) at org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:60 4) at org.apache.log4j.xml.XMLWatchdog.doOnChange(DOMConfigurator.java:861) at org.apache.log4j.helpers.FileWatchdog.checkAndConfigure(FileWatchdog.jav a:88) at org.apache.log4j.helpers.FileWatchdog.<init>(FileWatchdog.java:57) at org.apache.log4j.xml.XMLWatchdog.<init>(DOMConfigurator.java:853) at org.apache.log4j.xml.DOMConfigurator.configureAndWatch(DOMConfigurator.j ava:584) at org.apache.qpid.server.Main.configureLogging(Main.java:507) at org.apache.qpid.server.Main.startup(Main.java:251) at org.apache.qpid.server.Main.execute(Main.java:196) at org.apache.qpid.server.Main.<init>(Main.java:96) at org.apache.qpid.server.Main.main(Main.java:455) log4j:WARN No appenders could be found for logger (org.apache.qpid.server.registry.ApplicationRegistry). log4j:WARN Please initialize the log4j system properly. Regards, Senaka On Tue, May 20, 2008 at 3:00 AM, Robert Greig <[EMAIL PROTECTED]> wrote: > 2008/5/19 Senaka Fernando <[EMAIL PROTECTED]>: > > > What about writing our own variant? Refer [1] > > Yes, that is what I meant. You will either have to modify log4j or > find a way to replace enough bits that we can handle errors. It may > turn out to be a hassle to replace classes entirely, which is why I > wondered if modifying log4j might be simpler. For example, adding a > callback handler to the public API so that we can take action on > error. > > RG >
