To give a little history, we had lots of users who complained about this - they *really* don't want us to ship log4j config files with our release. It caused them endless pain trying to sort out classpath order with a whole bundle of 3rd party libaries.
Marnie On Tue, Sep 22, 2009 at 2:58 PM, Rajith Attapattu <rajit...@gmail.com>wrote: > On Tue, Sep 22, 2009 at 9:46 AM, Martin Ritchie <ritch...@apache.org> > wrote: > > 2009/9/22 Rajith Attapattu <rajit...@gmail.com>: > >> Martin, > >> > >> IMO our releases should have a sensible default logging level and is > >> something that most users expect. > >> So I don't think we should be asking users to set > >> -Dlog4j.configuration=client.log4j > >> > >> However I agree we could use a log4j.properties in our client instead > >> of a log4j.xml (all though this sounds more like a hack to me as this > >> is nothing more than making use of a backwards compatibility feature > >> of log4j) > > > > I wasn't suggesting that we rename it log4j.properties. I don't think > > we should include any log4j.* files in any of our jars, broker > > included. > > Disagree. By default we should not be doing debug logging !!! > It really affects performance and most of the time the end users don't > know what's the reason. > For Qpid users performance is paramount and when potential users > evaluate us we are at a disadvantage bcos out of the box we suck due > to excessive logging. IMO this is not acceptable and have heard > complaints about this from many users. > > We need to make the clients as easy to work with as possible and out > of the box our clients should perform reasonably well. > > >> I am also not sure about having the log4j.properties in the common > module. > >> > >> I recognize the issue of having a conflict in case the user tries to > >> bundle his own log4j.xml in a jar without using an explicit path. > >> Log4j really sucks. I am not sure why it defaults to debug in the first > place :) > > > > Better than none IMHO. > > > >> Anyways would it be acceptable for you if we remove the > >> log4j.properties from the common (provided it is not used anywhere) > >> and then put that in the client module? Sorry IMO the existing > >> client.log4j is not a proper solution. > > > > If you want to include a log4j.xml I don't really have an issue with > > that as long as it is not in our jars. When it is in the jar then it > > basically down to your classpath what logging you get, and that isn't > > something that end users always have control over. Sure they should > > call their logging something else and not log4j.xml but who are we to > > dictate how users configure their logging. By having a log4j.xml in > > our classes we are demanding that they have control over their > > classpath or use a name that is not log4j.xml. > > > > Take a look at Commons they don't provide logging configuration as > > that is not hard to add to your application configuration. > > <logger name="org.apache.commons"> > > <level value="WARN"/> > > </logger> > > > > I really don't see that Qpid should be any different. Shipping logging > > is nice for the examples and I beleive the example.jar does have > > logging defined in it. Including default logging in our jars I would > > say would be more of a nightmare for our end users. > > > > The client logging actually uses slf4j so seems even more of an odd > > fit to include a log4j configuration. > > In our releases we ship the log4j adapter as the default binding for > slf4j. If thats the case then we need to fix the log4j config. > > > Cheers > > Martin > > > >> Regards, > >> > >> Rajith > >> > >> On Tue, Sep 22, 2009 at 6:42 AM, Martin Ritchie <ritch...@apache.org> > wrote: > >>> Rajith, > >>> > >>> One of the reasons we do not currently have a log4j.xml file in the > >>> client package is that all our users will pick this up. > >>> As you say on QPID-2113 Log4j will scan the classpath looking for > >>> log4j.xml then log4j.properties. If it finds one then it will use it. > >>> I'm also not convinced we should have the log4j.properties in common > >>> as log4j can default to that. IIRC the common default used to be used > >>> by our tests. Our systests now use their own configuration and so the > >>> common one can probably be removed. > >>> > >>> Users should be given assistence on configuring their log4j but we > >>> should not bundle a log4j.* in our jars as that will make their > >>> debugging very difficult. Log4j debug will show it is using a > >>> log4j.xml file but not which jar it was loaded from. If your users > >>> bundle all their application files in to a jar, including their log4j > >>> configuration then you are relying on the classpath to select the > >>> log4j.* file to use. > >>> > >>> If users are having difficulty with excessive DEBUG messages then I > >>> would suggest that we simply need to advertise the client.log4j file > >>> that we ship better. > >>> Asking users to set -Dlog4j.configuration=client.log4j to get our > >>> default logging is much easier to explain IMHO than explaining why a > >>> users log4j.xml configuration file is not working. > >>> > >>> Regards > >>> > >>> Martin > >>> > >>> > >>> 2009/9/22 <raj...@apache.org>: > >>>> Author: rajith > >>>> Date: Tue Sep 22 00:13:05 2009 > >>>> New Revision: 817457 > >>>> > >>>> URL: http://svn.apache.org/viewvc?rev=817457&view=rev > >>>> Log: > >>>> This is a fix for QPID-2113 > >>>> I didn't meddle with the existing log4j.properties file present in the > common module as it maybe used in the broker. > >>>> However a cursory glance at the etc directory revealed that the the > broker too has a log4j.xml file. > >>>> > >>>> So perhaps the log4j.properties files in the common module is not > really needed. > >>>> (The settings given i the log4j.xml under the client module could be > overriden by explicitly specifying a log4.xml file using -Dlog.configuration > property) > >>>> > >>>> Added: > >>>> qpid/trunk/qpid/java/client/src/main/java/log4j.xml > >>>> > >>>> Added: qpid/trunk/qpid/java/client/src/main/java/log4j.xml > >>>> URL: > http://svn.apache.org/viewvc/qpid/trunk/qpid/java/client/src/main/java/log4j.xml?rev=817457&view=auto > >>>> > ============================================================================== > >>>> --- qpid/trunk/qpid/java/client/src/main/java/log4j.xml (added) > >>>> +++ qpid/trunk/qpid/java/client/src/main/java/log4j.xml Tue Sep 22 > 00:13:05 2009 > >>>> @@ -0,0 +1,36 @@ > >>>> +<!-- > >>>> + > >>>> + - > >>>> + - Licensed to the Apache Software Foundation (ASF) under one > >>>> + - or more contributor license agreements. See the NOTICE file > >>>> + - distributed with this work for additional information > >>>> + - regarding copyright ownership. The ASF licenses this file > >>>> + - to you under the Apache License, Version 2.0 (the > >>>> + - "License"); you may not use this file except in compliance > >>>> + - with the License. You may obtain a copy of the License at > >>>> + - > >>>> + - http://www.apache.org/licenses/LICENSE-2.0 > >>>> + - > >>>> + - Unless required by applicable law or agreed to in writing, > >>>> + - software distributed under the License is distributed on an > >>>> + - "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY > >>>> + - KIND, either express or implied. See the License for the > >>>> + - specific language governing permissions and limitations > >>>> + - under the License. > >>>> + - > >>>> +--> > >>>> + > >>>> +<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/";> > >>>> + <appender name="console" class="org.apache.log4j.ConsoleAppender"> > >>>> + <param name="Target" value="System.out"/> > >>>> + <layout class="org.apache.log4j.PatternLayout"> > >>>> + <param name="ConversionPattern" value="%-5p %c{1} - > %m%n"/> > >>>> + </layout> > >>>> + </appender> > >>>> + > >>>> + <logger name="org.apache.qpid"> > >>>> + <level value="warn"/> > >>>> + <appender-ref ref="console" /> > >>>> + </logger> > >>>> + > >>>> +</log4j:configuration> > >>>> > >>>> > >>>> > >>>> --------------------------------------------------------------------- > >>>> Apache Qpid - AMQP Messaging Implementation > >>>> Project: http://qpid.apache.org > >>>> Use/Interact: mailto:commits-subscr...@qpid.apache.org > >>>> > >>>> > >>> > >>> > >>> > >>> -- > >>> Martin Ritchie > >>> > >>> --------------------------------------------------------------------- > >>> Apache Qpid - AMQP Messaging Implementation > >>> Project: http://qpid.apache.org > >>> Use/Interact: mailto:dev-subscr...@qpid.apache.org > >>> > >>> > >> > >> > >> > >> -- > >> Regards, > >> > >> Rajith Attapattu > >> Red Hat > >> http://rajith.2rlabs.com/ > >> > >> --------------------------------------------------------------------- > >> Apache Qpid - AMQP Messaging Implementation > >> Project: http://qpid.apache.org > >> Use/Interact: mailto:dev-subscr...@qpid.apache.org > >> > >> > > > > > > > > -- > > Martin Ritchie > > > > --------------------------------------------------------------------- > > Apache Qpid - AMQP Messaging Implementation > > Project: http://qpid.apache.org > > Use/Interact: mailto:dev-subscr...@qpid.apache.org > > > > > > > > -- > Regards, > > Rajith Attapattu > Red Hat > http://rajith.2rlabs.com/ > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org > >
