Paul, > I've got the SocketReceiver stuff working, but found out that > the plugin > architecture can only be accessed via a log4j.xml config file > (it doesn't > load the plugin through PropertyConfigurator). Will this be > an issue in the > future? Be nice for PropertyConfigurator to be able to handle > all the things > DOMConfigurator can.
I need to review PropertyConfigurator to see if we can modify it to support plugins. I think it is doable, just haven't had time to look at it. > In it's simplest form, I was hoping for the user to define a > local log4j > config file that the Chainsaw gui finds or is provided with, > and that config > file provides the details of all the Receiver classes that > bring in external > events to the local log4j bus, plus the defined > ChainsawAppender (and in the > future, more than one). Sounds good. > This works great, but it relies on the local Log4J to be > initialised. I > first modified the Main.initLog4J() method to initialize via > a new log4j.xml > file, but eventually found that log4j was being initilized > twice! The first > lot was because the chainsaw package classes have various > Logger.getLogger(this.getClass()) methods, and they get there > first. Then > finally the initLog4J() method is getting called and an additional > ChainsawAppender is being created. Can you just define -Dlog4j.configuration=[your file name here] in the command line to start Chainsaw? Log4j will initialize itself using the file, which can contain the configuration for the reciever(s) and ChainsawAppender. Or you could have Chainsaw look for a specific file name at startup and then call DOMConfigurator to configure using it (or eventually use PropertyConfigurator when property files are supported). Am I missing something here? -Mark --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
