> -----Original Message----- > From: Rajith Attapattu [mailto:[email protected]] > Sent: 08 March 2010 20:42 > To: [email protected] > Subject: Re: Java Client Logging (yet again !) >
<snip> > > > > I'd say the ones inside the test and broker jars can go as well, or > at least > > can be renamed something other than log4j.[xml|properties] so you > need to > > specifically invoke their usage. > > We currently use the ones in the test modules to control the logging > for our test out put. > The broker is a different story from the client. > The broker will be run standalone more often than not (there will be > cases where the broker would also be embedded) and there will certain > expectations from the end user w.r.t. logging. > Therefore I think we do need to have some logging work out of the box > with appropriate configuration. > </snip> The broker is usually controlled from its etc/log4j.xml file which isn't on the class path and so can remain untouched, plus the first thing it does on startup is stop log4j wondering off around the class path looking for default configurations. The properties file that is in the broker jar can be renamed to anything and still be used by the broker as a fallback since it looks for it by name (which should have really already been changed from log4j.properties but wasn't). The other files needn't be called log4j.[xml|properties] to be used for what they are currently, since their use could as easily be set via the log4j system properties (in some cases they already are I believe) and in fact that would actually help ensure you were getting what you expected rather than leaving it up to class path ordering and use of the first log4j.xml (or failing that, log4j.properties) file on the class path. --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
