> From: Rajith Attapattu [mailto:rajit...@gmail.com] > Sent: 08 March 2010 15:42 > To: dev@qpid.apache.org > Subject: Java Client Logging (yet again !) > > Hi All, > > The current out of the box performance for the java client is somewhat > impacted by the log4j issues. > The solution I provided (adding a log4j.xml) for the client jar is > totally wrong and no better than the previous solution. > Also the code base is littered with log4j.xml files, especially in the > management client. > So even if the client.jar does not contain a log4j.xml, one of those > files in the management (or even the broker.jar) would be picked if > they are in the classpath. > > > Robert Gordfrey had done some excellent work in introducing a logging > façade via sl4j. > Yet we ship the releases with log4j bindings with all sorts of > log4j.xml which really defeats the purpose of the logging façade. > Lets not force a logging mechanism on the client - which is indeed the > intention behind the logging façade. > Log4j defaults to "DEBUG" (if not configured properly) which results > in piss poor performance. > We also need to ship something - so that some basic logging works, > preferably at "WARN" > > In order to fix these issues I suggest the following. > > 1. (a) Ship with slf4j-simple which defaults to "INFO" and prints to > std err. > (b) Ship our own binding which defaults to "WARN" (or even > "ERROR") and prints to std out > (c) Ship nothing with clear docs on how to get a binding of their > choice. > (*) Actually the README in the release should clearly indicate how > to configure the logging. >
I would go with c) here, as a) doesn't seem any more helpful than giving instructions on how to do it properly and b) seems like it would be a waste of effort. > 2. Get rid of all the log4j.xml (and log4j.properties) files in the > code base except in the test jars and the broker jar. > Please lets get rid of all log4j stuff from the common and client > modules. > In the README file we should clearly indicate how to configure > logging and a special note that if log4j is used, an explicitly > configured log4j.xml should be used to avoid having some other > log4j.xml being accidentally loaded from the classpath. > 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. > 3. From the next release we need to ship separate binaries for the > broker, client and management bits. We already do release separate bundles for pretty much everything (Client, Broker, QMan[management-client], and JMX Management Consoles). From the next release I would suggest that we stop shipping the 'java bundle' binary which mashes most of those contents together. > All though this is a topic of it's own, I'd like to take this > opportunity to mention that several customers/users have complained > above the excess number of jars and requests a list of absolute > minimum needed for the client. We have had some extraneous jars in the client bundle, I removed some just after 0.6 branched from trunk. There are a few remaining jars we only use 1 class or so from, so if we really care about reducing it some more we could repackage those class files or factor their usage out. > > Comments and suggestions are very welcome ! > > Regards, > > Rajith > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
