You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@qpid.apache.org by ra...@apache.org on 2009/09/22 02:13:06 UTC
svn commit: r817457 - /qpid/trunk/qpid/java/client/src/main/java/log4j.xml
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-subscribe@qpid.apache.org
Re: svn commit: r817457 - /qpid/trunk/qpid/java/client/src/main/java/log4j.xml
Posted by Marnie McCormack <ma...@googlemail.com>.
... and we had *loads* of complaints about this previously ;-(
Marnie
On Tue, Sep 22, 2009 at 11:42 AM, Martin Ritchie <ri...@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 <ra...@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-subscribe@qpid.apache.org
> >
> >
>
>
>
> --
> Martin Ritchie
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
Re: svn commit: r817457 - /qpid/trunk/qpid/java/client/src/main/java/log4j.xml
Posted by Carl Trieloff <cc...@redhat.com>.
Martin Ritchie wrote:
> 2009/9/22 Rajith Attapattu <ra...@gmail.com>:
>
>> Martin/Marnie,
>>
>> As I mentioned in one of my previous emails, I recognized the issue
>> with having a log4j.xml in the classpath.
>> Therefore I proposed to convert the log4j.xml to a log4j.properties.
>> The current behaviour is totally unacceptable and believe me there is
>> a fair number of folks who have complained about this as well.
>>
>> So I guess using a log4j.properties file in the client module is a
>> reasonable compromise as
>>
>> a) It avoids the issue of conflicting log4j.xml and avoids the
>> horrible classpath ordering issues (note the classpath issue is still
>> going to be there if users are still using the old log4j.properties
>> format instead of the new log4j.xml).
>>
>
> log4j.properties is still searched for by log4j if it cannot find a
> log4j.xml so I don't see how renaming it fixes the issue, it just
> requires users to call their configuration log4j.xml rather than
> log4j.properties. What if they want log4j.properties.
>
>
>> b) It fixes the default logging from debug to warn.
>>
>
> Writing tests that are representative need to have representative
> logging. When it comes to writing performance tests the test writer
> really needs to know what they are doing and if they don't know what
> their logging is, and by not configuring it they demonstrate that they
> don't, then they are going to be having some real difficulties.
>
> I find it so hard to believe that users of org.apache.* libraries have
> never had to set up their logging. We use commons in the java broker
> and when we upgraded to 1.6 the logging went from zero to a good 400%
> increase on the normal broker startup.
>
> Perhaps we could do something fancy with a static logging
> initialisation class. That sets org.apache.qpid to WARN if there is no
> logger defined for it. I'm not sure that slf4j will let us know that
> logging has been configured.
>
> What does ActiveMQ do? As another Apache's JMS provider I would expect
> to behave at least as well as they do.
>
>
My 2 cents is that I don't think we should be setting debug logging out
of the box. How to achieve
that in the Java client, I'm not the right one to comment.
Carl.
Re: svn commit: r817457 - /qpid/trunk/qpid/java/client/src/main/java/log4j.xml
Posted by Martin Ritchie <ri...@apache.org>.
2009/9/22 Rajith Attapattu <ra...@gmail.com>:
> Martin/Marnie,
>
> As I mentioned in one of my previous emails, I recognized the issue
> with having a log4j.xml in the classpath.
> Therefore I proposed to convert the log4j.xml to a log4j.properties.
> The current behaviour is totally unacceptable and believe me there is
> a fair number of folks who have complained about this as well.
>
> So I guess using a log4j.properties file in the client module is a
> reasonable compromise as
>
> a) It avoids the issue of conflicting log4j.xml and avoids the
> horrible classpath ordering issues (note the classpath issue is still
> going to be there if users are still using the old log4j.properties
> format instead of the new log4j.xml).
log4j.properties is still searched for by log4j if it cannot find a
log4j.xml so I don't see how renaming it fixes the issue, it just
requires users to call their configuration log4j.xml rather than
log4j.properties. What if they want log4j.properties.
> b) It fixes the default logging from debug to warn.
Writing tests that are representative need to have representative
logging. When it comes to writing performance tests the test writer
really needs to know what they are doing and if they don't know what
their logging is, and by not configuring it they demonstrate that they
don't, then they are going to be having some real difficulties.
I find it so hard to believe that users of org.apache.* libraries have
never had to set up their logging. We use commons in the java broker
and when we upgraded to 1.6 the logging went from zero to a good 400%
increase on the normal broker startup.
Perhaps we could do something fancy with a static logging
initialisation class. That sets org.apache.qpid to WARN if there is no
logger defined for it. I'm not sure that slf4j will let us know that
logging has been configured.
What does ActiveMQ do? As another Apache's JMS provider I would expect
to behave at least as well as they do.
Regards
Martin
> Regards,
>
> Rajith
>
> On Tue, Sep 22, 2009 at 10:02 AM, Marnie McCormack
> <ma...@googlemail.com> wrote:
>> 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 <ra...@gmail.com>wrote:
>>
>>> On Tue, Sep 22, 2009 at 9:46 AM, Martin Ritchie <ri...@apache.org>
>>> wrote:
>>> > 2009/9/22 Rajith Attapattu <ra...@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 <ri...@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 <ra...@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-subscribe@qpid.apache.org
>>> >>>>
>>> >>>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> --
>>> >>> Martin Ritchie
>>> >>>
>>> >>> ---------------------------------------------------------------------
>>> >>> Apache Qpid - AMQP Messaging Implementation
>>> >>> Project: http://qpid.apache.org
>>> >>> Use/Interact: mailto:dev-subscribe@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-subscribe@qpid.apache.org
>>> >>
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Martin Ritchie
>>> >
>>> > ---------------------------------------------------------------------
>>> > Apache Qpid - AMQP Messaging Implementation
>>> > Project: http://qpid.apache.org
>>> > Use/Interact: mailto:dev-subscribe@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-subscribe@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-subscribe@qpid.apache.org
>
>
--
Martin Ritchie
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: svn commit: r817457 - /qpid/trunk/qpid/java/client/src/main/java/log4j.xml
Posted by Rajith Attapattu <ra...@gmail.com>.
Martin/Marnie,
As I mentioned in one of my previous emails, I recognized the issue
with having a log4j.xml in the classpath.
Therefore I proposed to convert the log4j.xml to a log4j.properties.
The current behaviour is totally unacceptable and believe me there is
a fair number of folks who have complained about this as well.
So I guess using a log4j.properties file in the client module is a
reasonable compromise as
a) It avoids the issue of conflicting log4j.xml and avoids the
horrible classpath ordering issues (note the classpath issue is still
going to be there if users are still using the old log4j.properties
format instead of the new log4j.xml).
b) It fixes the default logging from debug to warn.
Regards,
Rajith
On Tue, Sep 22, 2009 at 10:02 AM, Marnie McCormack
<ma...@googlemail.com> wrote:
> 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 <ra...@gmail.com>wrote:
>
>> On Tue, Sep 22, 2009 at 9:46 AM, Martin Ritchie <ri...@apache.org>
>> wrote:
>> > 2009/9/22 Rajith Attapattu <ra...@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 <ri...@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 <ra...@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-subscribe@qpid.apache.org
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Martin Ritchie
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> Apache Qpid - AMQP Messaging Implementation
>> >>> Project: http://qpid.apache.org
>> >>> Use/Interact: mailto:dev-subscribe@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-subscribe@qpid.apache.org
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > Martin Ritchie
>> >
>> > ---------------------------------------------------------------------
>> > Apache Qpid - AMQP Messaging Implementation
>> > Project: http://qpid.apache.org
>> > Use/Interact: mailto:dev-subscribe@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-subscribe@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-subscribe@qpid.apache.org
Re: svn commit: r817457 - /qpid/trunk/qpid/java/client/src/main/java/log4j.xml
Posted by Marnie McCormack <ma...@googlemail.com>.
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 <ra...@gmail.com>wrote:
> On Tue, Sep 22, 2009 at 9:46 AM, Martin Ritchie <ri...@apache.org>
> wrote:
> > 2009/9/22 Rajith Attapattu <ra...@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 <ri...@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 <ra...@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-subscribe@qpid.apache.org
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Martin Ritchie
> >>>
> >>> ---------------------------------------------------------------------
> >>> Apache Qpid - AMQP Messaging Implementation
> >>> Project: http://qpid.apache.org
> >>> Use/Interact: mailto:dev-subscribe@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-subscribe@qpid.apache.org
> >>
> >>
> >
> >
> >
> > --
> > Martin Ritchie
> >
> > ---------------------------------------------------------------------
> > Apache Qpid - AMQP Messaging Implementation
> > Project: http://qpid.apache.org
> > Use/Interact: mailto:dev-subscribe@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-subscribe@qpid.apache.org
>
>
Re: svn commit: r817457 - /qpid/trunk/qpid/java/client/src/main/java/log4j.xml
Posted by Rajith Attapattu <ra...@gmail.com>.
On Tue, Sep 22, 2009 at 9:46 AM, Martin Ritchie <ri...@apache.org> wrote:
> 2009/9/22 Rajith Attapattu <ra...@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 <ri...@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 <ra...@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-subscribe@qpid.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Martin Ritchie
>>>
>>> ---------------------------------------------------------------------
>>> Apache Qpid - AMQP Messaging Implementation
>>> Project: http://qpid.apache.org
>>> Use/Interact: mailto:dev-subscribe@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-subscribe@qpid.apache.org
>>
>>
>
>
>
> --
> Martin Ritchie
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@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-subscribe@qpid.apache.org
Re: svn commit: r817457 - /qpid/trunk/qpid/java/client/src/main/java/log4j.xml
Posted by Martin Ritchie <ri...@apache.org>.
2009/9/22 Rajith Attapattu <ra...@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.
> 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.
Cheers
Martin
> Regards,
>
> Rajith
>
> On Tue, Sep 22, 2009 at 6:42 AM, Martin Ritchie <ri...@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 <ra...@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-subscribe@qpid.apache.org
>>>
>>>
>>
>>
>>
>> --
>> Martin Ritchie
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:dev-subscribe@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-subscribe@qpid.apache.org
>
>
--
Martin Ritchie
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: svn commit: r817457 - /qpid/trunk/qpid/java/client/src/main/java/log4j.xml
Posted by Rajith Attapattu <ra...@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 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 :)
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.
Regards,
Rajith
On Tue, Sep 22, 2009 at 6:42 AM, Martin Ritchie <ri...@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 <ra...@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-subscribe@qpid.apache.org
>>
>>
>
>
>
> --
> Martin Ritchie
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@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-subscribe@qpid.apache.org
Re: svn commit: r817457 - /qpid/trunk/qpid/java/client/src/main/java/log4j.xml
Posted by Martin Ritchie <ri...@apache.org>.
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 <ra...@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-subscribe@qpid.apache.org
>
>
--
Martin Ritchie
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org