On Thu, Aug 13, 2009 at 2:21 PM, Robbie Gemmell<[email protected]> wrote:
> Which (finally, sorry for the length of email) leads me to general > startup behaviour regarding logging configuration. What do we think is > the proper course of action to take at startup? If the etc/log4j.xml > file is missing or unreadable at the moment, the broker starts with > the fallback from (one of) the internal jar configurations. If the XML > is invalid in any way, it starts up with whatever does make it through > the configuration process, plus whatever came from the defaults inside > (one of) the jars. Should this be continued, but more strictly, so > that any issue with the XML causes use of a well defined fallback (at > startup only), or should a more firm stance be taken that the broker > wont start when an existing+readable but somehow malformed XML > configuration is present? 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, JMS, other messaging love http://qpid.apache.org "A witty saying proves nothing" - Voltaire --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
