On Sat, Jan 18, 2014 at 6:21 PM, Nick Williams < nicho...@nicholaswilliams.net> wrote:
> 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 > Hawaiian = no sympathy from the peanut gallery ;) G > > 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<http://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<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: garydgreg...@gmail.com | ggreg...@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 >>>> >>>> >>>> >>> >>> >>> -- >>> Matt Sicker <boa...@gmail.com> >>> >>> >>> >> >> >> -- >> E-Mail: garydgreg...@gmail.com | ggreg...@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: garydgreg...@gmail.com | ggreg...@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
