Robbie thx for your comments ! On Mon, Mar 8, 2010 at 2:27 PM, Robbie Gemmell <[email protected]> wrote: >> From: Rajith Attapattu [mailto:[email protected]] >> Sent: 08 March 2010 15:42 >> To: [email protected] >> 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.
The problem with (c) is that the client will not work out of the box, unless the user downloads a binding and get it going. I agree with you that it's no more helpful than (a), but then again we will have some users who just don't care and only want something that will work out of the box, rather than something that throws an exception. > >> 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. 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. > >> 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). Ah my bad !! > From the next > release I would suggest that we stop shipping the 'java bundle' binary which > mashes most of those contents together. I still think there are folks would need the bundle, so I don't recommend getting rid of it. > >> 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:[email protected] > > > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] > > -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/ --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
