I actually think Ralph's is a decently elegant solution:
<logger name="org.apache.foo" level="info" markers="CONFIG,INIT">
Except that I suggest that this should mean (instead of AND-ing it all
together):
if ( level == LEVEL || marker == CONFIG || marker == INIT )
log( );
N
Sent from the Hawaiian airlines terminal after 10 hours of traveling and 6 more
ahead of me, so please ignore delusional and delirious replies and frequent
typos
On Jan 18, 2014, at 3:05 PM, Scott Deboy wrote:
> Expression filter from log4j 1 already supports all of this and hasn't had to
> change for years. Markers could be supported as a property with almost zero
> work.
>
> On Jan 18, 2014 2:52 PM, "Gary Gregory" <garydgreg...@gmail.com> wrote:
> On Sat, Jan 18, 2014 at 5:26 PM, Ralph Goers <ralph.go...@dslextreme.com>
> wrote:
> We could address that by allowing a Markers attribute in all the same places
> a level attribute is supported. The only issue with that is that this would
> be very limited since there are more ways to use Markers. For example
> specifying
>
> <logger name=“org.apache.foo” level=“info” markers=“CONFIG,INIT”>
>
> would mean that only events that meet the level criteria and have a CONFIG or
> INIT marker would be logged.
>
> On the other hand we could do
>
> <logger name=“org.apache.foo” level=“info” expression=“Marker == CONFIG ||
> Marker == INIT”>
>
> All this would require is someone to implement an ExpressionFilter and then
> modifying logger to accept the expression attribute as a short hand way of
> calling it.
>
> Bleh, why not use JavaScript, it's baked in the JRE. Otherwise, this language
> risks to grow...
>
> Gary
>
>
> Ralph
>
> On Jan 18, 2014, at 2:12 PM, Nicholas Williams
> <nicho...@nicholaswilliams.net> wrote:
>
>> I prefer to avoid markers whenever possible. Unlike levels, markers require
>> some amount of configuration to get them to log/not log when desired. They
>> don't "just work."
>>
>> N
>>
>> Sent from my iPhone from LAX baggage claim, so please forgive brief replies
>> and frequent typos
>>
>> On Jan 18, 2014, at 14:01, Matt Sicker <boa...@gmail.com> wrote:
>>
>>> Markers all around! No logging levels, just allow markers to have ordinals
>>> or bit-flags to allow more flexible filtering.
>>>
>>> Sorry, nothing useful to add beyond wild speculations.
>>>
>>>
>>> On 18 January 2014 15:15, Ralph Goers <ralph.go...@dslextreme.com> wrote:
>>> Actually, here is how I would prefer it. Let’s see if it makes sense to
>>> anyone else.
>>>
>>> FATAL - Hopefully, almost never logged because the system is crashing.
>>> ERROR - Something affecting the usability of the system occurred.
>>> WARN - Something not nice, but probably recoverable occurred. May lead to
>>> errors later.
>>> INFO - Something of general interest, but not necessarily significant.
>>> DIAG or DIAGNOSTIC - Events that can be used by operations or users to
>>> diagnose problems in the system.
>>> DEBUG - Used by developers for internal debugging.
>>> VERBOSE - Used to log minute details of the system. As its dictionary
>>> definition implies this is extremely chatty.
>>> TRACE - Adds tracing of method entry and exit, possibly object creation and
>>> initialization.
>>>
>>> I believe these should be enough for anybody. I still think CONFIG is a
>>> Marker at the INFO level. The advantage of being a Marker is that it can be
>>> enabled regardless of its level and enabling it doesn’t imply enabling
>>> other levels.
>>>
>>> Ralph
>>>
>>>
>>> On Jan 18, 2014, at 1:03 PM, Gary Gregory <garydgreg...@gmail.com> wrote:
>>>
>>>> On Sat, Jan 18, 2014 at 2:21 PM, Ralph Goers <ralph.go...@dslextreme.com>
>>>> wrote:
>>>> STEP? No clue what that means.
>>>>
>>>> Gary, if you want to implement VERBOSE between INFO and DEBUG I’m OK with
>>>> that, but what will that map to in SLF4J, etc. DEBUG?
>>>>
>>>> Sounds OK, I can see it as debug data, but for users, instead of
>>>> developers.
>>>>
>>>> Gary
>>>>
>>>> And yes, something on the web site should document our recommended usage
>>>> for levels and markers.
>>>>
>>>> Ralph
>>>>
>>>>
>>>>
>>>> On Jan 18, 2014, at 10:53 AM, Gary Gregory <garydgreg...@gmail.com> wrote:
>>>>
>>>>> Ah, my view of VERBOSE is that it is _more_ information, hence INFO <
>>>>> VERBOSE < DEBUG; while it sounds like Ralphs sees it as more DEBUG data.
>>>>>
>>>>> For me DEBUG data is going to be already verbose, even more than
>>>>> 'verbose'.
>>>>>
>>>>> What is interesting (to me) is that DEBUG is often misused based on this
>>>>> basic mix: debug messages can be for users *and/or* for developers, there
>>>>> is no distinction in the audience.
>>>>>
>>>>> For example, as a user, I want to get data to help me debug my
>>>>> configuration and my process. As a developer, I want to debug the code.
>>>>> These can be two very different set of data.
>>>>>
>>>>> But we do not have DEBUG_USER and DEBUG_DEV levels. I would see INFO next
>>>>> to VERBOSE as useful to users. Then DEBUG and TRACE useful for
>>>>> developers. Each app can have its convention of course, but it would be
>>>>> nice to have the distinction available through levels for developers to
>>>>> use.
>>>>>
>>>>> I see TRACE as method entry and exit type of logging, *very* *low* level
>>>>> stuff.
>>>>>
>>>>> We could also have both (ducking for projectiles):
>>>>>
>>>>> INFO
>>>>> VERBOSE
>>>>> DEBUG
>>>>> STEP
>>>>> TRACE
>>>>>
>>>>> Gary
>>>>>
>>>>>
>>>>> On Sat, Jan 18, 2014 at 12:47 PM, Ralph Goers
>>>>> <ralph.go...@dslextreme.com> wrote:
>>>>> Oops. I just noticed you proposed that VERBOSE be between INFO and DEBUG.
>>>>> Now that I don’t understand. My experience is that VERBOSE is usually
>>>>> more detailed than debug messages, not less.
>>>>>
>>>>> Ralph
>>>>>
>>>>> On Jan 18, 2014, at 9:44 AM, Ralph Goers <ralph.go...@dslextreme.com>
>>>>> wrote:
>>>>>
>>>>>> I understand the need for CONFIG. However it isn’t clear to me whether
>>>>>> it belongs between INFO and WARN or DEBUG and INFO. That is because it
>>>>>> typically would be used to log configuration during startup. That
>>>>>> doesn’t necessarily imply that you would then want to see all INFO
>>>>>> messages as well. Due to that, it would make more sense to me to make a
>>>>>> CONFIG marker.
>>>>>>
>>>>>> I don’t really understand the point of FINE or FINER.
>>>>>>
>>>>>> On the other hand, VERBOSE does make a bit more sense, but I’m
>>>>>> struggling with how that is any different than TRACE. I guess the idea
>>>>>> is that TRACE is for control flow (entry, exit) and VERBOSE is for more
>>>>>> detailed debug messages? I suppose I can go along with that argument,
>>>>>> but again one could just as easily create a VERBOSE marker and attach it
>>>>>> to either TRACE or DEBUG. I guess I wouldn’t object if VERBOSE was
>>>>>> added as a Level but I’m not really convinced it is necessary either.
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Jan 18, 2014, at 7:08 AM, Remko Popma <remko.po...@gmail.com> wrote:
>>>>>>
>>>>>>> I've always liked Ralph's argument that Markers give users much more
>>>>>>> flexibility than any predefined Levels.
>>>>>>> I would prefer to stick to the log4j/slf4j level names.
>>>>>>>
>>>>>>>
>>>>>>> On Sat, Jan 18, 2014 at 10:32 PM, Gary Gregory <garydgreg...@gmail.com>
>>>>>>> wrote:
>>>>>>> Interesting, I have been wanting a VERBOSE level better INFO and DEBUG.
>>>>>>>
>>>>>>> See
>>>>>>> http://mail-archives.apache.org/mod_mbox/logging-log4j-dev/201310.mbox/%3CCACZkXPxNwYbn__CbXUqFhC7e3Q=kee94j+udhe8+6jiubcz...@mail.gmail.com%3E
>>>>>>>
>>>>>>> You'll have to dig a little in that ref to find my proposal, sorry I'm
>>>>>>> on my phone ATM.
>>>>>>>
>>>>>>> It sounds like we see logging configuration messages differently
>>>>>>> though. I do not like the name CONFIG because it does not sound like a
>>>>>>> level to me. Otoh, many command lines have a verbose AND a debug
>>>>>>> switch. So it makes sense to me too have corresponding levels.
>>>>>>>
>>>>>>> Gary
>>>>>>>
>>>>>>>
>>>>>>> -------- Original message --------
>>>>>>> From: Nick Williams
>>>>>>> Date:01/17/2014 23:50 (GMT-05:00)
>>>>>>> To: Log4J Developers List
>>>>>>> Subject: Web Issues, Logging Levels, and GA
>>>>>>>
>>>>>>> Wanted to update y'all. As you know, I've been very absent lately due
>>>>>>> to the book consuming every minute of my free time. I know I haven't
>>>>>>> been contributing my due, and for that please accept my sincerest
>>>>>>> apologies. The book is finally done (goes on sale next month!) and I
>>>>>>> can get back to regular life. I'm going to be out of town for the next
>>>>>>> week on a much-needed vacation with very limited access to email. I'll
>>>>>>> be back the weekend of January 25-26, and that weekend I will be
>>>>>>> spending almost the entire time finally dealing with the 8-10 web
>>>>>>> application-related bugs. After that, I don't see any encumbrances to
>>>>>>> releasing 2.0.0.GA.
>>>>>>>
>>>>>>> Except...
>>>>>>>
>>>>>>> Logging Levels. We kinda-sorta talked about this a few months ago, and
>>>>>>> a few months before that, and a few months before that, but we never
>>>>>>> actually DID anything about it. It's clear by now that my "extendable
>>>>>>> enum" proposal (that would be a drop-in replacement for and binary
>>>>>>> compatible with the current Level enum) is not going to be accepted.
>>>>>>> Absent any other proposals, I suggest we add the following new levels
>>>>>>> before GA:
>>>>>>>
>>>>>>> CONFIG - Between INFO and WARN, mapped to INFO for bridges to other
>>>>>>> frameworks that don't have an equivalent level
>>>>>>>
>>>>>>> FINE - Between DEBUG and TRACE, mapped to TRACE for bridges to other
>>>>>>> frameworks that don't have an equivalent level
>>>>>>>
>>>>>>> I'll let y'all chat about that over the next week. ;-)
>>>>>>>
>>>>>>> Be back soon,
>>>>>>>
>>>>>>> Nick
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
>>>>>>> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>>>>> Java Persistence with Hibernate, Second Edition
>>>>> JUnit in Action, Second Edition
>>>>> Spring Batch in Action
>>>>> Blog: http://garygregory.wordpress.com
>>>>> Home: http://garygregory.com/
>>>>> Tweet! http://twitter.com/GaryGregory
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>>>> Java Persistence with Hibernate, Second Edition
>>>> JUnit in Action, Second Edition
>>>> Spring Batch in Action
>>>> Blog: http://garygregory.wordpress.com
>>>> Home: http://garygregory.com/
>>>> Tweet! http://twitter.com/GaryGregory
>>>
>>>
>>>
>>>
>>> --
>>> Matt Sicker <boa...@gmail.com>
>
>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> JUnit in Action, Second Edition
> Spring Batch in Action
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
