2009/10/26 Rajith Attapattu <[email protected]>: > Hi Martin, > > I noticed that the log4j.xml in the client module had been deleted in rev > 828019 > I didn't see anything in the commit log for that revision, so I assume > it was a mistake.
It was, thanks for reminding me though, it is now back at r830102. As I said in my earlier email I have huge reservations about the inclusion of this file. We should at most be including an example configuration file along with documentation of how to use it. The JAR should not have any file that will automatically be picked up by log4j, i.e log4j.xml or log4j.properties. > Anyways once that is removed we are now back to square one. > We *cannot* release the java client with debug logging enabled as it > introduces a massive performance drop. I would actually go the other way and say we *cannot* release *with* this file. Leaving our users log4j configuration up to the vagaries of classpath is not acceptable IMHO. Try starting the java broker without the org.apache.commons setting to WARN. It logs at debug by default. Checkout the activemq release there is no log4j.[xml|propertiy] files in their release. I would bet that ALL library jars released from Apache have no log4j.* files contained within them. If a user is writing a performance test they should really be giving their logging some consideration and not just using a default value. I library class such as our qpid-client should not be making any assumptions about how our users what their logging set up. If they don't take the time to configure logging then the performance may well be terrible. As an example take a look at the commons package. We started using that in the Java broker for XML parsing and until we set it back to WARN in our log4j config it more than doubled the standard broker startup logging. > We need to make things work as best as possible out of the box. > First impressions count and we don't want to loose potential users > bcos they ran their tests while debugging was enabled. I agree that things need to work out the box and they do currently. If we start adding default log4j config then we may end up breaking users configuration and making it very difficult to find out why. > Most users do not expect debug logging to be enabled by default. > You only turn debug on when you need to debug an issue. I would again agree here, but I would argue that this user is not the same as the developer above. Developers need t be aware of the implications of using a library. If actually we shipped a useful client README file that explained how to configure usable logging then things would be better. INFO/DEBUG is not a useful distinction IMHO, INFO doesn't have enough, DEBUG is to chatty. Sometimes you want to just have status messages about new model objects rather than logging every byte of every frame. Martin > Regards, > > Rajith Attapattu > Red Hat > http://rajith.2rlabs.com/ > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] > > -- Martin Ritchie --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
