I updated the startup behaviour a bit when I put in the new validation checking QpidLog4JConfigurator earlier. I added a property to the qpid-server scripts that disables Log4J's default initialisation to stop it wondering off and mixing configurations. The broker then checks if the indicated XML configuration is present/readable:
If it isn't, the properties file in the broker jar is loaded which makes the broker default to a level according to -Damqj.logging.level (currently set to INFO in the qpid-run script) with a basic console appender. If this approach is considered ok I think the default should be WARN, and perhaps we should make the properties file a more fully configured fallback. If it is readable, then it is parsed and validated against the DTD to ensure it generates no warnings, and then the level values specified for the loggers in it are checked to ensure they are valid levels (Log4J will silently default them to DEBUG if they aren't). If either of these steps fail then the startup is aborted, causing a shutdown. The approach is perhaps a little contradictory in that not specifying one at all allows startup but presenting a somehow invalid configuration does not. Should it be changed further to either shutdown in both cases, or fallback to the properties file in both cases ? Robbie > -----Original Message----- > From: Aidan Skinner > Sent: 14 August 2009 12:02 > > I think failing to start is the right thing here, defaulting to > something like debug will be too chatty and makes finding the > origional error hard to find. > > - Aidan --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
