logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: Verbose logging level
Date Tue, 08 Oct 2013 07:03:40 GMT
On Tue, Oct 8, 2013 at 1:47 AM, Ralph Goers <ralph.goers@dslextreme.com>wrote:

> Is there some reason you can't do:
>
> public static final Marker VERBOSE_MARKER =
> MarkerManager.getMarker("VERBOSE");
>
>
> and then logger.info(VERBOSE_MARKER, "Reading Accounts");
>
> then in your configuration you would do
>
> <MarkerFilter marker="VERBOSE" onMatch="ACCEPT" onMismatch="DENY"/>
>
> and finally, in your Appender you could use a PatternLayout that includes
>
> pattern="%p %marker %msg"
>
> You could also wrap the marker in a %replace so that you don't end up with
> two spaces when there is not Marker.
>

Sure, I could do all that, I was just reading up on markers actually, but
it sure is more complicated than just using a Level that fits the exact
right need! ;)


>
> The point is that the purpose of Markers is to fill the need for these
> kinds of things without needing to create an endless number of logging
> levels. Remember that every new Level that gets added causes 14 new methods
> to be added to the Logger interface.
>

I am not so concerned about 14 new methods as long as Level concepts are
good, not too many like with what HTTPD seems to have done with 16 levels,
but just right. I think we could definitely add another level or two. The
user stories are there IMO, especially if we give good examples. The HTTPD
example with "Trace1, 2, 3" and so on is lame.


> Another consideration is that if a new level was added between info and
> debug when mapping the Log4j 2 API to SLF4J we would have to make an
> arbitrary choice as to whether the events should be mapped to INFO or DEBUG
> since SLF4J (as well as JCL) don't have a corresponding level. OTOH, JUL
> has a CONFIG level between FINE and INFO, which seems to correlate to the
> examples you show.
>

I'm Log4j 2 all the way for now. I do not have the need for other framework
unless it is to support 3rd party jars.

Gary


>
>
> On Oct 7, 2013, at 8:50 PM, Gary Gregory <garydgregory@gmail.com> wrote:
>
> On Mon, Oct 7, 2013 at 11:16 PM, Scott Deboy <scott.deboy@gmail.com>wrote:
>
>> If your examples included loggers I think it would show these added
>> verbose entries would be another logger at INFO but not a separate severity.
>>
>> I think of levels in terms of relative numeric severity. DEBUG < INFO
>> <WARN <ERROR etc.  Chainsaw supports this kind of logic in filtering
>> colorizing and searching for events.
>>
>> Where would verbose go? I would put it below DEBUG myself.
>>
>
> I should not have proposed a name for this level since 'verbose' means
> different things to different people. As I stated in my original message,
> this new level would be between INFO and DEBUG.
>
> Gary
>
>
>> Btw this advice to use another logger in most cases doesn't mean there
>> aren't cases where additional levels aren't useful.
>>
>> Just something to think about.
>>
>> Scott
>> On Oct 7, 2013 7:30 PM, "Gary Gregory" <garydgregory@gmail.com> wrote:
>>
>>> Hi All:
>>>
>>> I've just come across the need for distinguishing log entries somewhat
>>> between what INFO and DEBUG provide.
>>>
>>> I think of the DEBUG level as a watermark where data is provided for
>>> developers and support to do deep debugging. INFO is for users. But I see
>>> the need now for providing an easy way to give user more information (hence
>>> VERBOSE or another word) which is not at the DEBUG level of detail.
>>>
>>> Ideally, I'd like this in INFO mode:
>>>
>>> INFO Reading configuration
>>> INFO Running server
>>>
>>> Then in a new VERBOSE mode:
>>>
>>> INFO Reading configuration
>>> VERBOSE Reading accounts
>>> VERBOSE Reading this config data
>>> VERBOSE Reading that config data
>>> VERBOSE Reading other config data
>>> INFO Running server
>>>
>>> The in DEBUG mode, you'd get all the things that are real debug
>>> information like
>>>
>>> DEBUG Configuration location was not provided on the command line.
>>> DEBUG Searching classpath for configuration: cp entries
>>> DEBUG Searching user home for configuration: c:\users\...
>>> DEBUG Found configuration at location xzy, last modified date: ...
>>> INFO Reading configuration
>>>
>>> Thoughts?
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>> Spring Batch in Action <http://www.manning.com/templier/>
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Mime
View raw message