Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (herse.apache.org: domain of jason.dillon@gmail.com
 designates 64.233.166.182 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:mime-version:in-reply-to:references:content-type:message-id:content-transfer-encoding:from:subject:date:to:x-mailer:sender;
        b=CT7aWN+xWl2mr25yjAZNU8OlDDRkxarMbnzXbAnfIqWlUPPXLwd39n4q7frsHdC4cPQAFqfJMhddgplDGSjZuZF2ZorcMz1UOX4jJwPxHTuwEZkm7ABuBbXKGTG4voJLzFz7cB2rGKHORKPBC5YwwqgLtAGTcM/SLExwlhNJvZ0=
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <5eb405c70704042011s17c64f2as8301c428bd97260@mail.gmail.com>
References: <20070404200532.364CE1A9838@eris.apache.org>
 <D554A61C-53FD-43A5-A852-49B2F2E0F78C@planet57.com>
 <46140CEA.5090704@apache.org>
 <59D627DD-03C2-4DCB-BF73-751A6A36A31A@planet57.com>
 <46145F7B.4010207@gmail.com>
 <0BD0B3CA-5DCC-4414-8F23-B3242FC4ADD8@planet57.com>
 <5eb405c70704042011s17c64f2as8301c428bd97260@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <BE62B1FB-B99C-48B6-ACD9-C88F4C3BDB5B@planet57.com>
Content-Transfer-Encoding: 7bit
From: Jason Dillon <jason@planet57.com>
Subject: Re: svn commit: r525594 -
 /geronimo/server/trunk/assemblies/geronimo-boilerplate-minimal/src/main/resources/var/log/server-log4j.properties
Date: Wed, 4 Apr 2007 20:13:49 -0700
To: dev@geronimo.apache.org
Sender: Jason Dillon <jason.dillon@gmail.com>

I'm okay with that... though I still don't like having to use the  
config for docs... but ya, commented out bits are much better than  
defaulting them to FATAL of OFF.

--jason


On Apr 4, 2007, at 8:11 PM, Jarek Gawor wrote:

> I think it would be ok to add these logging statements to the
> configuration file but have them commented out. For example:
>
> # log4j.logger.org.apache.commons.httpclient=DEBUG
>
> That way the user will not have to search the online docs to figure
> out the right debug statements.
>
> Jarek
>
> On 4/4/07, Jason Dillon <jason@planet57.com> wrote:
>> On Apr 4, 2007, at 7:31 PM, Lin Sun wrote:
>> > I proposed to add them in just because it took me quite a while to
>> > figure out how to turn on debug logs for Axis2.  This is needed if
>> > anyone ever needs to debug an Axis2 prob or report an Axis2 JIRA.
>> > I don't want others to go through the effort thus I feel it is
>> > appropriate to have them in so that people can change to DEBUG or
>> > TRACE whenever needed.
>> >
>> > It is perfectly fine if you want to have INFO or ERROR instead of
>> > FATAL.  To answer your question, I don't really see much/any output
>> > of these loggers w/o the limits.
>>
>> Wiki pages are quite useful for explain these types of things to
>> people.  If there isn't already there should be a comprehensive guide
>> on how to deal with logging in Geronimo.  I don't think it is
>> appropriate to use the actually logging configuration file as
>> documentation... though these aren't commented out with docs, they
>> are actually setting the levels which I think is even worse.
>>
>> I would recommend creating that wiki page (or updating it if one
>> exists, I've not looked recently at what is there).
>>
>> And if you want, add _commented_ examples of how to enable DEBUG/
>> TRACE, but don't limit things that aren't insanely noisy by default.
>> That will only leave folks scratching their heads when they expect to
>> see the output.
>>
>> And I would recommend that we should never be limiting categories to
>> FATAL or ERROR... those log messages generally indicate problems
>> which should not be swallowed by default.
>>
>> --jason
>>
>>
>>
>> > Lin
>> >
>> > Jason Dillon wrote:
>> >> I don't think we should be trying to taylor the logging output of
>> >> Geronimo to match what other component communities have for their
>> >> projects.
>> >> I'm okay with with levels for axis, though I think FATAL is not
>> >> the correct level to limit them at by default.  In most cases I
>> >> would expect to see INFO+ captured in log files, but when limiting
>> >> logger levels like this they will never make it to the file  
>> appender.
>> >> But the others, like httpclient for example.  Users may be using
>> >> Geronimo w/o any WS muck, using httpclient and expecting to see
>> >> log messages.  Limiting these logger here is a very bad idea, as
>> >> it will leave those users wonder where the logs went and causing
>> >> them to ping the lists asking what is going on.
>> >>  * * *
>> >> In general I'm -1 on limiting loggers to FATAL, unless for some
>> >> reason the component spits out a ton of ERROR messages, and
>> >> similarly I'm -1 on limiting loggers to ERROR unless they spit out
>> >> a ton of WARN messages.  And in both cases if those libraries are
>> >> spitting out so much junk, then we are either integrating them
>> >> improperly or their codebase is incorrectly using logging... in
>> >> both cases something should be fixed, we shouldn't be silently
>> >> ignoring them.
>> >>  * * *
>> >> What is the output of these loggers w/o the limits?
>> >> --jason
>> >> On Apr 4, 2007, at 1:39 PM, Donald Woods wrote:
>> >>> The log4j.properties used by Axis2 includes those 4 values set to
>> >>> FATAL, so I'm trying to match our log output to what the Axis2
>> >>> community is used to seeing and ships today.
>> >>>
>> >>> Also, adding these values into our file allows users to easily
>> >>> see how to turn on debug info for a component (Axis and Axis2 in
>> >>> this case) without having to dig through the component source or
>> >>> pinging our user mailing list for the info.....
>> >>>
>> >>>
>> >>> -Donald
>> >>>
>> >>> Jason Dillon wrote:
>> >>>> Why?
>> >>>> I don't think its a good idea to keep growing the list of logger
>> >>>> levels in our log4j configuration file like this.  For one or
>> >>>> two its okay, but probably not for so many.  I mean, do these
>> >>>> libraries really spit out so much information that we have to
>> >>>> limit them all to FATAL?
>> >>>> The default output level is currently set to WARN unless the -v
>> >>>> or -vv flag is passed to the server, which will set to DEBUG and
>> >>>> TRACE respectively.  With logger levels set explicitly , then
>> >>>> adding -v or -vv will have zero affect.  And the way we
>> >>>> currently configure these levels affect both the console and log
>> >>>> files.
>> >>>> I think that changing these levels to FATAL is harmful and
>> >>>> should be reverted... unless there is a really good reason for
>> >>>> it... which is what I'm asking right now.  What is the reason we
>> >>>> need to have these explicit logger levels configured here?
>> >>>> --jason
>> >>>> On Apr 4, 2007, at 1:05 PM, dwoods@apache.org wrote:
>> >>>>> Author: dwoods
>> >>>>> Date: Wed Apr  4 13:05:30 2007
>> >>>>> New Revision: 525594
>> >>>>>
>> >>>>> URL: http://svn.apache.org/viewvc?view=rev&rev=525594
>> >>>>> Log:
>> >>>>> GERONIMO-3064 Add axis2 log4j configure properties so that
>> >>>>> people can turn on axis2 logs in geronimo.  Thanks Lin.  I also
>> >>>>> added the Axis v1 log categories.
>> >>>>>
>> >>>>> Modified:
>> >>>>>     geronimo/server/trunk/assemblies/geronimo-boilerplate-
>> >>>>> minimal/src/main/resources/var/log/server-log4j.properties
>> >>>>>
>> >>>>> Modified: geronimo/server/trunk/assemblies/geronimo- 
>> boilerplate-
>> >>>>> minimal/src/main/resources/var/log/server-log4j.properties
>> >>>>> URL: http://svn.apache.org/viewvc/geronimo/server/trunk/
>> >>>>> assemblies/geronimo-boilerplate-minimal/src/main/resources/var/
>> >>>>> log/server-log4j.properties?
>> >>>>> view=diff&rev=525594&r1=525593&r2=525594
>> >>>>>  
>> ==================================================================
>> >>>>> ============
>> >>>>> --- geronimo/server/trunk/assemblies/geronimo-boilerplate-
>> >>>>> minimal/src/main/resources/var/log/server-log4j.properties
>> >>>>> (original)
>> >>>>> +++ geronimo/server/trunk/assemblies/geronimo-boilerplate-
>> >>>>> minimal/src/main/resources/var/log/server-log4j.properties Wed
>> >>>>> Apr  4 13:05:30 2007
>> >>>>> @@ -115,10 +115,22 @@
>> >>>>>  # Prints various stuff during startup
>> >>>>>  log4j.logger.org.apache.juddi.registry.RegistryServlet=WARN
>> >>>>>
>> >>>>> -
>> >>>>>  # Prints various stuff when the portal is used
>> >>>>>  log4j.logger.org.apache.pluto.portalImpl.Servlet=WARN
>> >>>>> +
>> >>>>>  # Prints stuff for AJAX calls
>> >>>>>   
>> log4j.logger.uk.ltd.getahead.dwr.impl.DefaultConfiguration=WARN
>> >>>>>  log4j.logger.uk.ltd.getahead.dwr.impl.ExecuteQuery=WARN
>> >>>>>  log4j.logger.uk.ltd.getahead.dwr.util.Logger=WARN
>> >>>>> +
>> >>>>> +# Axis log output
>> >>>>> +log4j.logger.org.apache.axis.enterprise=FATAL
>> >>>>> +log4j.logger.org.apache.axis.TIME=OFF
>> >>>>> +log4j.logger.org.apache.axis.EXCEPTIONS=FATAL
>> >>>>> +
>> >>>>> +# Axis2 log output
>> >>>>> +log4j.logger.org.apache.axis2.enterprise=FATAL
>> >>>>> +log4j.logger.de.hunsicker.jalopy.io=FATAL
>> >>>>> +log4j.logger.httpclient.wire.header=FATAL
>> >>>>> +log4j.logger.org.apache.commons.httpclient=FATAL
>> >>>>> +
>> >>>>>
>> >>>>>
>> >
>>
>>