From log4j-user-return-27912-apmail-logging-log4j-user-archive=logging.apache.org@logging.apache.org Wed Oct 19 02:56:55 2016 Return-Path: X-Original-To: apmail-logging-log4j-user-archive@www.apache.org Delivered-To: apmail-logging-log4j-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 15F81195AE for ; Wed, 19 Oct 2016 02:56:55 +0000 (UTC) Received: (qmail 67329 invoked by uid 500); 19 Oct 2016 02:56:49 -0000 Delivered-To: apmail-logging-log4j-user-archive@logging.apache.org Received: (qmail 67275 invoked by uid 500); 19 Oct 2016 02:56:49 -0000 Mailing-List: contact log4j-user-help@logging.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Log4J Users List" Reply-To: "Log4J Users List" Delivered-To: mailing list log4j-user@logging.apache.org Received: (qmail 67264 invoked by uid 99); 19 Oct 2016 02:56:49 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 19 Oct 2016 02:56:49 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id DDAA31806CD for ; Wed, 19 Oct 2016 02:56:48 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.179 X-Spam-Level: * X-Spam-Status: No, score=1.179 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd3-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=msn.com Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id qbDDbKXfwSBW for ; Wed, 19 Oct 2016 02:56:39 +0000 (UTC) Received: from SNT004-OMC3S14.hotmail.com (snt004-omc3s14.hotmail.com [65.55.90.153]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 623655F47D for ; Wed, 19 Oct 2016 02:56:38 +0000 (UTC) Received: from NAM04-CO1-obe.outbound.protection.outlook.com ([65.55.90.135]) by SNT004-OMC3S14.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Tue, 18 Oct 2016 19:56:32 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=msn.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=t8iQW3NP3U/AHzMb5bQRSNjOZTcN/pNMnu4VxhL/82o=; b=N5e2RdC8NaD32mwc1fpPIJ1OHzjxFhHDByIV08ttgaIjMJQe/NyhyHOHikUT65en2QM1j9LW/o+k3c9LgeVE5+bOlvB3DzxO5b3WzihIxP46S7zgupoDPnQNEI8RTfCMuUdoWoN081JDoq2lbdy983ZoNprdCMMOl+50ADeMj9lbFoZJydnXKI1WRS4oA/a5Sxi7y2fUc3K82PrVq9xV4hi7VfZVpEOM/06S0O14aocC6nAsrjBlkAhLM0q0qgxi5oQKRPEVeCs0Y3J286or2+0RAZmTYTxI9sXuzifrp8recLzveh/2SCcoQUSagdtD1oGVgl+ByBynXV2+HXOhgg== Received: from BN3NAM04FT018.eop-NAM04.prod.protection.outlook.com (10.152.92.58) by BN3NAM04HT119.eop-NAM04.prod.protection.outlook.com (10.152.93.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.629.5; Wed, 19 Oct 2016 02:56:30 +0000 Received: from BLUPR10MB0833.namprd10.prod.outlook.com (10.152.92.60) by BN3NAM04FT018.mail.protection.outlook.com (10.152.92.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.629.5 via Frontend Transport; Wed, 19 Oct 2016 02:56:30 +0000 Received: from BLUPR10MB0833.namprd10.prod.outlook.com ([10.163.216.11]) by BLUPR10MB0833.namprd10.prod.outlook.com ([10.163.216.11]) with mapi id 15.01.0659.025; Wed, 19 Oct 2016 02:56:30 +0000 From: Nicholas Duane To: Log4J Users List Subject: Re: approach for defining loggers Thread-Topic: approach for defining loggers Thread-Index: AQHQ6qonASyt7VPGJki6vrVErdHZb54z0iGAgnvU3suAAFc4AIABjtfH Date: Wed, 19 Oct 2016 02:56:30 +0000 Message-ID: References: <8111409E-064B-47E5-AD6E-F692F0D791C6@dslextreme.com> <94F63A48-75C8-42CA-8E03-008405523D74@dslextreme.com> <7464449D-8947-4D64-A39C-7E01C15208B3@dslextreme.com> <75EB9EDC-2A6B-4D20-99DD-79B6861E393D@dslextreme.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: logging.apache.org; dkim=none (message not signed) header.d=none;logging.apache.org; dmarc=none action=none header.from=msn.com; x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [u5Ap3OpZDYShBayifXHzQ5QO7BxKfuiR] x-eopattributedmessage: 0 x-microsoft-exchange-diagnostics: 1;BN3NAM04HT119;6:a9bdvyude028rj4mhwRJWe9Isc1h8mVugrwEq81ddnKcgvEHoCM9jVHJDs5DOfVqYlHmvJnPO6R5dfQm4OpNy02fleaGJ3KqYYyzEdW6v0wpwZmj1wSo8cVNecUyIQI3k3WI+OMX67nzDGTnhlChYMTUIPOLzJhkbIJ1FtM/VJJ8Jo5TmkEMTriovfYosyXd82Q1aciw+Tm2Rjwmb8QVeWQiDeqi1/CJ98QylOQo01wzKmFSrcpwKyoiVTQ18SQ5d2/KJcjDNjXYp5fx/kAq7UU8LIdv6DQLenE5COJ7Y9M=;5:iErFCrCvdHuJewkKV+KOoSv+JhWO7AyWv2syHF8QnXH+1+DZibgJSnjr5vPkIsizfsgD1fO6V1WfZkIQCYv0cIWZkFyzL5Xwiue3R9w3M88tWbvjzWlgIOWpDRTUmPSjvfbZjXGI4bvB/o6MP/49fg==;24:xGJExNZs6VT0lBselNKRZ9B6VVvpJuK2Lbf1uvWtvjEIXmznVGqEAagiLDjwx7HwAOconhwdD33gOFFfE+QZvFsib3bJCHpWAhOaz7qTO44=;7:EqlglUIuP7Vr6J3+VxxzyqS5iGG8pyXgi/qt73Eze3rrpPJbPp3zO9cfaQrTjsBKsLcaVNkvXKNMwCxktUXy8yD1O+1xA8GLh/Rve3pC4YG3bBgoyh4URCC5uSJMFRtUtRRJ7osEjzkYAet/UkCbEPvtkobZGNlDfRmVGk4ay2EOVkkjEJhfGKhAedC6gLD0YFwnBh8oLDst7UuJXgeRmAeF72dflR2sKk6p0TDzx4fR1FRgObEfbMpOvNwwHusi+bZyWswrgPbW6Y4dXicAz5gbUqEXOrX73esZYsiJArXWPdzAXL8ryfJnCvNtNeKqVE/LkVM2qg6CQ1ZVO4umgA== x-forefront-antispam-report: EFV:NLI;SFV:NSPM;SFS:(10019020)(98900003);DIR:OUT;SFP:1102;SCL:1;SRVR:BN3NAM04HT119;H:BLUPR10MB0833.namprd10.prod.outlook.com;FPR:;SPF:None;LANG:en; x-ms-office365-filtering-correlation-id: 34abe8ac-3d42-40e3-2427-08d3f7cb870f x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(1601124038)(1603103081)(1601125047);SRVR:BN3NAM04HT119; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(432015012)(82015046);SRVR:BN3NAM04HT119;BCL:0;PCL:0;RULEID:;SRVR:BN3NAM04HT119; x-forefront-prvs: 0100732B76 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BLUPR10MB08334CE172A37500C7095160DBD20BLUPR10MB0833namp_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2016 02:56:30.3578 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3NAM04HT119 X-OriginalArrivalTime: 19 Oct 2016 02:56:32.0344 (UTC) FILETIME=[65A6AD80:01D229B4] --_000_BLUPR10MB08334CE172A37500C7095160DBD20BLUPR10MB0833namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I don't believe there is a severity to our compliance and business events. = I could be wrong. If they had a severity it would certainly make them fit= into the logging model more cleanly, but I just don't see it. And I just = had this discussion with one of my colleagues. They were suggesting a resu= lt code for a business event. However, I pointed out that you'd only need = that if you planned on logging failed business events, which is what he was= thinking. Would you just log the failed business event or maybe the faile= d business event and an error event? Would a failure business event go int= o the business event store or the critical diagnostic (errors, warnings, in= fo) store? We might have systems management people monitoring the critical= diagnostics store to see what, if any, issues are currently happening thus= just logging a failed business event might not set of any alarms. Though = you could say that a failed business event it not a critical diagnostics ev= ents. Maybe it's just a business failure event. For instance, low balance= . Though I probably see a low balance as yet another business event, not a= failure of some other business event. Just in case anyone is wondering I should probably make this clear, none of= the logging we're doing is for auditing. We made it perfectly clear that = events can be lost and thus you should not be using the logging frameworks = and these events to audit. I have a clear definition for an audit, "if you= fail to audit then you fail the application transaction". I'm thinking our compliance and business events would have fit nicely into = the EventLogger. As I mentioned, there are two issues I have with the even= t logger. Therefore I'm thinking that maybe we provide some methods to log= these events to the All level in an attempt to implement something similar= to the EventLogger but do it against a private logger. So something like = this (pseudo code): public class ExtensionMethods { public void LogEvent(Logger logger, object evnt); or public void LogEvent(Logger logger, String category, object evnt); } The other thing I'll need to make sure is that we have a way to distinguish= between our different categories of events. I won't use Markers as they d= on't exist on log4net and we have a "category" property anyway so I think I= can use that. Thanks, Nick ________________________________ From: Gary Gregory Sent: Monday, October 17, 2016 10:46 PM To: Log4J Users List Subject: Re: approach for defining loggers On Mon, Oct 17, 2016 at 4:27 PM, Nicholas Duane wrote: > Sorry to revive this old thread. However, we're in the process of adding > support for other "categories" of events and thus I wanted to first take = a > step back and try to ensure we're not convoluting things. > > > There was a requirement to log a "compliance" event under certain > conditions. We did not want to write our own logging framework and inste= ad > decided to use existing off-the-shelf logging frameworks. We have > applications on both Linux/Java, Windows/.NET and Windows/Java. Initiall= y > we chose log4net for Windows/.NET and log4j2 for Windows/Java and > Linux/Java. For these logging frameworks we wrote artifacts, appenders > basically, to help facilitate getting these events to our system. By the > way, our system will get the events centrally, possibly put them into a > relational database and also hand them off to another system which will g= et > them eventually to an HDFS backend. We also exposed methods for creating > this compliance event. The compliance event is basically a map. We chos= e > a map so that the event could also be extended by the application team in > case they needed to add additional properties which made sense for them. > > > We chose to create a custom level for this "compliance" event such that w= e > could filter out only these events and get them into our system. The > configuration example we created had our custom unix domain socket append= er > added to the root logger. It also contained a filter which filtered out > any events that weren't compliance events. The level we chose for > "compliance" was less critical than off and more critical than fatal as w= e > wanted to ensure that as long as logging wasn't turned off altogether our > events would get logged. > > > I want to go over a few suggestions that were made and explain why I > didn't make use of those suggestions. > > > 1. Since our "compliance" level didn't fit within the "vernacular" of the > existing levels we should not define this custom level. Instead we shoul= d > look at using markers. > Yes, this is a use case for markers. The level should be used to note how important is each compliance event. > > I am not that familiar with markers but did look into them when they were > suggested. While I don't have anything against markers in general there > were some downsides as I saw it. > > > a. Markers are not available, as far as I know, in log4net so we'd still > have to figure out something there. > Indeed, we really need a port of Log4j 2 to .NET. > > b. A bigger problem, at least I thought it was a bigger problem, was that > there would be confusion about what level to log the event at. I would > certainly not want to give an example as follows: > > > logger.debug(COMPLIANCE_MARKER, evnt); > > > or > > > logger.info(COMPLIANCE_MARKER, evnt); > > > or > > > logger.error(COMPLIANCE_MARKER, evnt); > > > ... > Think about: How important is this event? Are there different level of importance to the audience? > > > That just screams confusion to me. > > > 2. Use a dedicated logger to log all compliance events. > > > There were, as far as I could tell, a couple problems with this approach > also. > > > a. If everyone is using a single "well known" logger to log a specific > event category then I lose the logger "context" of who's logging the > event. As it stands now we're copying the logger name into a property we > call "eventSource". > A practice is to use one logger per class. Another is to use a higher-level logger to represent higher-level abstractions like a module. > > > b. You cannot turn on/off logging for a specific set of code. If it turn= s > out that we have some errant code which is using this well known logger > then we can't just turn off that code from logging as turning off the wel= l > know logger would turn it off for everyone using it. > > > I did look into the EventLogger and initially that seemed promising as I > guess it logs any event you give it at the "all" level. However, as a we= ll > known logger it suffers from the same issues above. > > > Now we're looking to add Business events. My initial thinking is that I > can do the same thing we did before. Add an additional custom level call= ed > "Business" and expose methods for creating a business event. I would NOT create a custom level. Instead, I would use a Logger called "Business". > Though unlike the compliance event, the application teams would be > defining the schema more so than our framework team. Thus any method we > expose would just be used as a starting point for setting the common > properties. You would use another instance of our unix domain socket > appender for these business events and forward them to a different locati= on > as business events would most likely have a different retention period th= an > compliance events. Plus you might also want them in a different store as > you may never need to query for both categories of events and thus no nee= d > to query against a larger set of data. > > > In addition we're planning to capture centrally what we refer to as > diagnostic events: error, info, warn, debug, trace, etc. However, we may > need to separate these out into two different categories: > critical-diagnostic and noncritical-diagnostic. This could be a user case for custom levels IF one is more important than the other which it sure sounds like it is. > The reason is that we don't want the potential of a critical diagnostic > event, let's say an error, queued up behind potentially thousands of > non-critical diagnostic events. So you see, the category also defines > aspects on how we handle events at the source. We separate at the sourc= e > based on category as it seems a reasonable place to do so. Also, you may > want different flush times for different categories. We have a process > which buffers, compresses and sends events centrally so we have the notio= n > of flush time. The buffers are flushed when they become full or the flus= h > time elapses. Errors, since they are more critical in monitoring systems= , > we'll most likely want to flush more often than say debug and trace event= s. > > > Sorry for the long winded explanation. Initially I was thinking that whe= n > we create an event we'd set its category. However, now I'm thinking the > category should be set by the act of logging the event at a level. In so= me > cases we have a 1:1 mapping from level to category, eg. compliance level = -> > compliance category. In some cases we have a many:1 mapping from level t= o > category, eg. error, info, warn -> critical-diagnostic. > > > We could also just define a single custom level, say "always_on", or > something like that. Then we provide some helper method to log our "new" > event categories (eg. business and compliance) at this level and have the > user specify the category, I guess similar to a marker. > Log4j has a level called ALL. I would really try to work hard to stay within the feature set before thinking about anything custom. If you can make critical-diagnostic and noncritical-diagnostic events to stock levels, that much the better. Gary > > > logEvent(Logger logger, String category, object evnt); > > > I guess it's similar to the EventLogger except that we're not using a > single well known logger and thus don't have the downsides of that which = I > pointed out earlier. > > > Any thoughts/suggestions would be appreciated. > > > Thanks, > > Nick > > ________________________________ > From: Mikael St=E5ldal > Sent: Wednesday, September 9, 2015 3:47 AM > To: Log4J Users List > Subject: Re: approach for defining loggers > > Then perhaps you should create your own facade for doing business event > logging, which could then forward them to Log4j in an appropriate way. > > On Wed, Sep 9, 2015 at 4:49 AM, Nicholas Duane wrote: > > > I was just about to reply to your previous email about using a single > > "business" logger, or some hierarchy of business loggers, to log busine= ss > > events and say that we might go that route. However, now that you > brought > > up the post from Ralph, which I just replied to, I'm thinking a logger > > won't work either for the same reason I listed in my reply to Ralph's > post. > > > > You could do: > > > > logger.info("Hello"); > > logger.fatal("Hello"); > > logger.error("Hello"); > > ... > > > > It's confusing as there are n ways to log a business event that way and > > they will all do the same thing. Which one should a developer choose. > > Should I say pick any one, it doesn't matter? > > > > Thanks, > > Nick > > > > > Date: Tue, 8 Sep 2015 19:28:21 -0700 > > > Subject: Re: approach for defining loggers > > > From: garydgregory@gmail.com > > > To: log4j-user@logging.apache.org > > > > > > Or > > > Logger logger =3D LogManager.getLogger("Business"); > > > ... > > > logger.info("Hello"); > > > > > > Gary > > > > > > On Tue, Sep 8, 2015 at 7:24 PM, Ralph Goers < > ralph.goers@dslextreme.com> > > > wrote: > > > > > > > Can you please clarify, =93If we had some way to know an event is a > > business > > > > event we wouldn=92t need level=94? I do not understand how you can= code > > > > logger.log(BUSINESS, msg) but you cannot code logger.info(BUSINESS= , > > msg). > > > > > > > > Ralph > > > > > > > > > On Sep 8, 2015, at 6:09 PM, Nicholas Duane wrote= : > > > > > > > > > > > > > > > > > > > > > > > > > I looked over that stackoverflow post and I'm still not seeing a > good > > > > match as a way for us to log our business events. > > > > > > > > > > A business event I guess is an event which extends whatever schem= a > we > > > > come up with for a business event. While an instance of this schem= a > > could > > > > be logged at any level, that really doesn't make sense in our > scenario, > > > > regardless of whether some marker was supplied. If we had some way > to > > know > > > > an event is a business event we wouldn't need level. We could of > > course > > > > add some property to our schema which indicates the 'category' of t= he > > > > event, 'business' being one such category. Instead we were thinkin= g > we > > > > could just use level to indicate that an event is a business event. > > > > > > > > > > As I mentioned, we're looking to capture 'trace' level events to > one > > > > store, 'info' - 'fatal' level events to another store, and 'busines= s' > > > > events to yet another store. For 'trace' and 'info' - 'fatal' it > seems > > > > reasonable to filter on level within the appender to get those even= ts > > to > > > > the appropriate location. It seemed reasonable to do something > > similar for > > > > 'business'. > > > > > > > > > > I also looked into the EventLogger but not sure that's appropriat= e. > > For > > > > one we lose the granularity to control a specific piece of code fro= m > > > > generating business events. This is most likely a non-issue as I > have > > > > mentioned that we don't want to turn business logging off. The oth= er > > is > > > > that we lose the name of the logger as it would be the same for > > everyone. > > > > Not sure this is that big a deal either as I guess you might be abl= e > to > > > > capture component name, though I would rather distinguish using > logger > > name. > > > > > > > > > > Thanks, > > > > > Nick > > > > > > > > > >> From: ralph.goers@dslextreme.com > > > > >> Subject: Re: approach for defining loggers > > > > >> Date: Mon, 7 Sep 2015 20:39:11 -0700 > > > > >> To: log4j-user@logging.apache.org > > > > >> > > > > >> I still don=92t understand why you don=92t want to use Markers. = They > > were > > > > designed exactly for the use case you are describing. > > > > >> > > > > >> You might set retention policies for debug vs info, error and > fatal, > > > > but a BUSINESS marker could cross-cut them all. That is exactly wh= y > > it is > > > > NOT a level. IOW, it gives you a second dimension for filtering. Ce= ki > > > > invented Markers when he created SLF4J. For his point of view see > > > > > > http://stackoverflow.com/questions/16813032/what-is- [http://cdn.sstatic.net/Sites/stackoverflow/img/apple-touch-icon@2.png?v=3D= 73d79a89bded&a] What is markers in Java Logging frameworks and that is a reason to use them= ? stackoverflow.com First time I hear about markers when read: http://slf4j.org/faq.html I chec= k available methods for Logger object: http://www.slf4j.org/api/org/slf4j/L= ogger.html http://logging.apache.org/log4j/2.x/ > markers-in-java-logging-frameworks-and-that-is-a-reason-to-use-them > [http://cdn.sstatic.net/Sites/stackoverflow/img/apple-touch- > icon@2.png?v=3D73d79a89bded&a] questions/16813032/what-is-markers-in-java-logging- > frameworks-and-that-is-a-reason-to-use-them> > > What is markers in Java Logging frameworks and that is a ...< > http://stackoverflow.com/questions/16813032/what-is- > markers-in-java-logging-frameworks-and-that-is-a-reason-to-use-them> > stackoverflow.com > This is a rehashed version my answer to the question "Best practices for > using Markers in SLF4J/Logback". Markers can be used to color or mark a > single log statement. > > > > > > < > > > > > > http://stackoverflow.com/questions/16813032/what-is- > markers-in-java-logging-frameworks-and-that-is-a-reason-to-use-them > [http://cdn.sstatic.net/Sites/stackoverflow/img/apple-touch- > icon@2.png?v=3D73d79a89bded&a] questions/16813032/what-is-markers-in-java-logging- > frameworks-and-that-is-a-reason-to-use-them> > > What is markers in Java Logging frameworks and that is a ...< > http://stackoverflow.com/questions/16813032/what-is- > markers-in-java-logging-frameworks-and-that-is-a-reason-to-use-them> > stackoverflow.com > This is a rehashed version my answer to the question "Best practices for > using Markers in SLF4J/Logback". Markers can be used to color or mark a > single log statement. > > > > > > >. > > > > >> > > > > >> Ralph > > > > >> > > > > >> > > > > >> > > > > >> > > > > >>> On Sep 7, 2015, at 5:54 PM, Nicholas Duane > wrote: > > > > >>> > > > > >>> If I'm attempting to control all the logging from the > configuration > > > > and I don't know the complete set of loggers in my application as > there > > > > could be 100's or 1000's, wouldn't it be hard to separate events > based > > on > > > > loggers? It would seem much easier to separate events based on > > level. In > > > > addition, level might be a more reasonable approach for separating. > > For > > > > example, if I want to send all events to some big-data backend I > might > > want > > > > to separate out traces and debug from info to fatal as traces and > > debug are > > > > most likely less important from a systems management aspect. My > > retention > > > > period for traces and debug might be just a couple days. The > retention > > > > period for info to fatal could be 30 days. Business level might be= 2 > > > > years. Any system management notifications would probably be drive= n > > off of > > > > info to fatal events and not trace and debug events, which is anoth= er > > > > reason you might want to separate by level. > > > > >>> > > > > >>> Thanks, > > > > >>> Nick > > > > >>> > > > > >>>> Subject: Re: approach for defining loggers > > > > >>>> From: ralph.goers@dslextreme.com > > > > >>>> Date: Mon, 31 Aug 2015 08:50:58 -0700 > > > > >>>> To: log4j-user@logging.apache.org > > > > >>>> > > > > >>>> A logging =93Level=94 is a level of importance. That is why th= ere > is a > > > > hierarchy. If you want informational messages then you also would > want > > > > warnings and errors. > > > > >>>> > > > > >>>> =93BUSINESS=94 does not convey the same meaning. Rather, it i= s some > > sort > > > > of category, which is what Markers are for. > > > > >>>> > > > > >>>> Using the class name as the logger name is a convention. If yo= u > > > > really want the class name, method name or line number then you > should > > be > > > > specifying that you want those from the logging event, rather than > the > > > > logger name. Unless location information is disabled you always ha= ve > > > > access to that information. > > > > >>>> > > > > >>>> In short, different loggers are used primarily as a way of > > grouping > > > > sets of messages - for example all org.hibernate events can be rout= ed > > to a > > > > specific appender or turned off en masse. Levels are used to filter > out > > > > noise across a set of logging events. Markers are used to categoriz= e > > > > logging events by arbitrary attributes. > > > > >>>> > > > > >>>> Ralph > > > > >>>> > > > > >>>> > > > > >>>>> On Aug 31, 2015, at 8:10 AM, Nicholas Duane > > wrote: > > > > >>>>> > > > > >>>>> Thanks for the feedback. I will look into Markers and MDC. > > > > >>>>> > > > > >>>>> With respect to using a separate logger, it would seem I woul= d > > lose > > > > the information about what application code, eg. the class logger, = is > > > > sourcing the event. We would like to have this information. On to= p > of > > > > that, it seems odd, maybe to me only, that for this new level we ha= ve > > our > > > > own logger. It seemed reasonable to me that this new event we want > to > > > > capture is just a new level. Just like a DEBUG event is different > > from an > > > > INFO event. If I define a BUSINESS level why would that not follow > the > > > > same design as the current levels? You wouldn't suggest having > > different > > > > loggers for TRACE DEBUG INFO WARN ERROR FATAL, would you? I think > one > > of > > > > the reasons someone on our side is suggesting I have separate logge= rs > > is > > > > that they think the overhead of filtering at the appender is going = to > > have > > > > a noticeable impact. Our plan, at least the one I have now in my > > head, is > > > > that we'll have some number of appenders in the root. We'll then > > filter x > > > > < INFO events to a tracing appender, INFO <=3D x <=3D FATAL to a lo= gging > > > > appender, and our custom level will go to another appender. > Thoughts? > > > > >>>>> > > > > >>>>> Thanks, > > > > >>>>> Nick > > > > >>>>> > > > > >>>>>> Subject: Re: approach for defining loggers > > > > >>>>>> From: ralph.goers@dslextreme.com > > > > >>>>>> Date: Sat, 29 Aug 2015 20:59:36 -0700 > > > > >>>>>> To: log4j-user@logging.apache.org > > > > >>>>>> > > > > >>>>>> > > > > >>>>>>> On Aug 29, 2015, at 7:44 PM, Nicholas Duane > > > > wrote: > > > > >>>>>>> > > > > >>>>>>> I'm curious if there is a prescribed approach to defining > > > > loggers. Let me state what my assumption is. I assume that normal= ly > > if > > > > some piece of code wants to log events/messages that it should > create a > > > > logger for itself. I guess a reasonable name to use is the class > name > > > > itself. In terms of logger configuration I would expect that no > > loggers > > > > are specified in the log4j configuration UNLESS is needs settings > other > > > > than the default. The root logger would specify the default > settings, > > eg. > > > > level and appenders. If some piece of code tied to a logger needs = to > > > > enable tracing in order to debug an issue then you would add that > > logger to > > > > the configuration and set the level less specific for that logger. > Is > > this > > > > a typical and reasonable approach? > > > > >>>>>> > > > > >>>>>> What you describe here is the common convention. It is a > > reasonable > > > > approach. > > > > >>>>>> > > > > >>>>>>> > > > > >>>>>>> I asked because we have the need for a new type of event. = To > > have > > > > this event flow to where we want it to flow the plan is to have a > > custom > > > > level and have all events at that level captured by a specific > > appender. > > > > My assumption was that for existing applications we'd just need to > add > > our > > > > appender to the root and add our custom level. The app would need = to > > be > > > > modified to log our new event at the custom level. However, someon= e > > > > suggested that we could also create a separate logger for this even= t. > > My > > > > thinking is that while we don't ever want to turn off logging of th= is > > > > event, loggers represent "event sources", e.g the code raising the > > events > > > > and thus having multiple different pieces of code use the same logg= er > > > > wouldn't allow you to turn on/off logging from those different > > sections of > > > > code independently. I think the current configuration includes all > the > > > > loggers. Normally I would expect there to be many, on the order of > > 10's or > > > > 100's, loggers within an application. However, in the case I was > given > > > > there were only a handful because I think this handful is shared. = So > > as I > > > > mentioned, this doesn't sound like an ideal design as you have less > > > > granularity on what you can turn on/off. > > > > >>>>>> > > > > >>>>>> You have a few options. Using a CustomLevel would not be the > > option > > > > I would choose. Creating a custom Logger will certainly work and > makes > > > > routing the message to the appropriate appender rather easy. Anoth= er > > > > approach is to use Markers. Markers are somewhat hierarchical so y= ou > > can > > > > use them for a variety of purposes. If you look at how Log4j handl= es > > event > > > > logging it actually does both - it specifies EventLogger as the nam= e > > of the > > > > logger to use and it uses Markers to identify the kind of event. > > > > >>>>>> > > > > >>>>>> A third option is to use the MDC or Logger properties. If yo= u > do > > > > that then you can have information included in the actual logging > event > > > > that can affect how it is routed. I also built a system that uses t= he > > > > RFC5424 format so that the event could have lots of key/value pairs > to > > > > identify the events. > > > > >>>>>> > > > > >>>>>> Unfortunately, without knowing more details I don=92t know t= hat > I > > can > > > > give you a better idea on how I would implement it. > > > > >>>>>> > > > > >>>>>> Ralph > > > > >>>>>> > > > > >>>>>> > > > > ------------------------------------------------------------ > --------- > > > > >>>>>> To unsubscribe, e-mail: > > log4j-user-unsubscribe@logging.apache.org > > > > >>>>>> For additional commands, e-mail: > > log4j-user-help@logging.apache.org > > > > >>>>>> > > > > >>>>> > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> > > --------------------------------------------------------------------- > > > > >>>> To unsubscribe, e-mail: log4j-user-unsubscribe@ > logging.apache.org > > > > >>>> For additional commands, e-mail: > > log4j-user-help@logging.apache.org > > > > >>>> > > > > >>> > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------ > --------- > > > > To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org > > > > For additional commands, e-mail: log4j-user-help@logging.apache.org > > > > > > > > > > > > > > > > > -- > > > E-Mail: garydgregory@gmail.com | ggregory@apache.org > > > Java Persistence with Hibernate, Second Edition > > > > > > JUnit in Action, Second Edition > > > Spring Batch in Action > > > Blog: http://garygregory.wordpress.com > [https://s0.wp.com/i/blank.jpg] > > Gary Gregory > garygregory.wordpress.com > Software construction, the web, and other techs > > > > > Home: http://garygregory.com/ > Gary Gregory > garygregory.com > Rocket | Seagull . I am a Software Architect for Seagull Software, a > division of Rocket Software. Rocket Seagull specializes in tools and > expertise to modernize ... > > > > > Tweet! http://twitter.com/GaryGregory > Gary Gregory (@GaryGregory) | Twitter > twitter.com > The latest Tweets from Gary Gregory (@GaryGregory). Principal Software > Engineer, author: Java Persistence Hibernate https://t.co/3F8sYxc0oq, > JUnit https://t.co/yXU1DqAMDG, Spring Batch https://t.co/XwoMNoBxh7. > U.S.A. > > > > > > > > > > -- > [image: MagineTV] > > *Mikael St=E5ldal* > Senior software developer > > *Magine TV* > mikael.staldal@magine.com > Regeringsgatan 25 | 111 53 Stockholm, Sweden | www.magine.com< > http://www.magine.com> > [https://de.magine.com/content/uploads/2016/09/magine_global_social.png]< > http://www.magine.com/> > > TV online with Magine TV > www.magine.com > Watch the TV you love, on any device, anywhere in Germany and Sweden and > find out more about our global OTT B2B solutions. Get started today. > > > > Privileged and/or Confidential Information may be contained in this > message. If you are not the addressee indicated in this message > (or responsible for delivery of the message to such a person), you may no= t > copy or deliver this message to anyone. In such case, > you should destroy this message and kindly notify the sender by reply > email. > -- E-Mail: garydgregory@gmail.com | ggregory@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 --_000_BLUPR10MB08334CE172A37500C7095160DBD20BLUPR10MB0833namp_--