Re: approach for defining loggers

hat. Thanks, Nick From: Gary Gregory <garydgreg...@gmail.com> 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 <nic...@msn.com> wrote: > Sorry to revi

Re: approach for defining loggers

ober 18, 2016 10:01 AM To: Log4J Users List Subject: Re: approach for defining loggers The “context” of the call is only grossly captured by the logger name, and that is only by convention. If you really want the name of the class then you need the location information, which gives you the class n

Re: approach for defining loggers

...@gmail.com>> > Sent: Monday, October 17, 2016 11:15 PM > To: Log4J Users List > Subject: Re: approach for defining loggers > > What about event logging? < > https://logging.apache.org/log4j/2.x/manual/eventlogging.html > <https://logging.apache.org/log4j/2.x

Re: approach for defining loggers

In some cases we have a many:1 mapping from level > to > > 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 metho

Re: approach for defining loggers

vel > to > > 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 categ

Re: approach for defining loggers

//www.ietf.org/rfc/rfc3164.txt <https://www.ietf.org/rfc/rfc3164.txt> [2] http://www.rsyslog.com/doc/v8-stable/configuration/filters.html <http://www.rsyslog.com/doc/v8-stable/configuration/filters.html> > >> Date: Thu, 10 Sep 2015 21:21:09 -0700 >> Subject: Re:

RE: approach for defining loggers

l is off. In my specific case, while I would of course need the event to be logged, I want to route specific types (/levels?) of events to specific appenders because different events are going to different locations. Thanks, Nick > Date: Thu, 10 Sep 2015 21:21:09 -0700 > Subject: Re:

Re: approach for defining loggers

> On Sep 11, 2015, at 3:50 PM, Gary Gregory wrote: > > > This updated text I hope will help: > > "No new loggers needed, just an additional parameter to your log call, > regardless of the level API used. > > Now, I can configure Log4j to log only events that contain

Re: approach for defining loggers

On Fri, Sep 11, 2015 at 4:23 PM, Ralph Goers wrote: > > > On Sep 11, 2015, at 3:50 PM, Gary Gregory > wrote: > > > > > > This updated text I hope will help: > > > > "No new loggers needed, just an additional parameter to your log call, > >

RE: approach for defining loggers

? Thanks, Nick > Date: Fri, 11 Sep 2015 16:46:14 -0700 > Subject: Re: approach for defining loggers > From: garydgreg...@gmail.com > To: log4j-user@logging.apache.org > > On Fri, Sep 11, 2015 at 4:23 PM, Ralph Goers <ralph.go...@dslextreme.com> > wrote: > > &g

Re: approach for defining loggers

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 > > > Subje

Re: approach for defining loggers

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: garydgreg...@gmail.com > > To: log4j-user@logging.apache.

Re: approach for defining loggers

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 able to > capture component name, though I would rather distinguish using logger name. > > Thanks, > Nick > > > From: ralph.go...@dslextreme.com > &

Re: approach for defining loggers

gging off. The other 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 able to capture component name, > though I would rather distinguish using logger name. > > Thanks, > Nick > >>

RE: approach for defining loggers

guess you might be able to capture component name, though I would rather distinguish using logger name. Thanks, Nick > From: ralph.go...@dslextreme.com > Subject: Re: approach for defining loggers > Date: Mon, 7 Sep 2015 20:39:11 -0700 > To: log4j-user@logging.apache.org >

Re: approach for defining loggers

e 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 able to > capture component name, though I would rather distinguish using logger name. > > > > Thanks, > > Nick > > > >> From: ralph.go...@

RE: approach for defining loggers

ogger.error(BUSINESS, msg); the users will ask us which one they should use. If they are all going to do the same thing then that's a problem. You don't want n ways to do the same thing as that will just cause confusion. Thanks, Nick > Subject: Re: approach for defining loggers > From:

RE: approach for defining loggers

ame 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: garydgreg...@gmail.com > To: log4j-user@logging.apache.org > > Or > Logger l

Re: approach for defining loggers

e same thing then that's a problem. You don't want n ways to do the same > thing as that will just cause confusion. > > Thanks, > Nick > >> Subject: Re: approach for defining loggers >> From: ralph.go...@dslextreme.com >> Date: Tue, 8 Sep 2015 19:24:32 -07

RE: approach for defining loggers

I will certainly look them over again. Thanks,Nick Original message From: Ralph Goers <ralph.go...@dslextreme.com> Date: 09/07/2015 9:39 PM (GMT-07:00) To: Log4J Users List <log4j-user@logging.apache.org> Subject: Re: approach for defining loggers I still don’t un

Re: approach for defining loggers

t; fatal could be 30 days. Business level might be 2 years. Any system > management notifications would probably be driven off of info to fatal events > and not trace and debug events, which is another reason you might want to > separate by level. > > Thanks, > Nick

Re: approach for defining loggers

ents and not trace and debug events, which is another reason you > might want to separate by level. > > Thanks, > Nick > > > Subject: Re: approach for defining loggers > > From: ralph.go...@dslextreme.com > > Date: Mon, 31 Aug 2015 08:50:58 -0700 > > To:

RE: approach for defining loggers

traces to one location, all info to fatal to another location and business events to yet a third location. Thanks, Nick > Date: Mon, 7 Sep 2015 18:35:13 -0700 > Subject: Re: approach for defining loggers > From: garydgreg...@gmail.com > To: log4j-user@logging.apache.org >

Re: approach for defining loggers

sounds like a single logger which I initially thought was > not required and instead the advice would be to log via whatever logger > you're using for your other events. However, maybe the EventLogger will > work. > > Thanks, > Nick > > > > Date: Mon, 31 Aug 2015 15:16:49 -

Re: approach for defining loggers

and instead the advice would be to log via whatever logger > you're using for your other events. However, maybe the EventLogger will > work. > > Thanks, > Nick > > > > Date: Mon, 31 Aug 2015 15:16:49 -0700 > > Subject: Re: approach for defining loggers > > From: gar

RE: approach for defining loggers

r you're using for your other events. However, maybe the EventLogger will work. Thanks, Nick > Date: Mon, 31 Aug 2015 15:16:49 -0700 > Subject: Re: approach for defining loggers > From: garydgreg...@gmail.com > To: log4j-user@logging.apache.org > > On Mon, Aug 31, 2015 a

Re: approach for defining loggers

;> >> Someone had mentioned using the EventLogger. I still have to look into >> that, but that sounds like a single logger which I initially thought was >> not required and instead the advice would be to log via whatever logger >> you're using for your other events. Howe

RE: approach for defining loggers

Subject: Re: approach for defining loggers > From: ralph.go...@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 <nic...@msn.com> wrote: > > > > I'm curious if there is

Re: approach for defining loggers

t;= x <= FATAL to a logging > appender, and our custom level will go to another appender. Thoughts? > > Thanks, > Nick > > > Subject: Re: approach for defining loggers > > From: ralph.go...@dslextreme.com > > Date: Sat, 29 Aug 2015 20:59:36 -0700 > > To: l

Re: approach for defining loggers

ilter x < INFO events to a tracing > appender, INFO <= x <= FATAL to a logging appender, and our custom level will > go to another appender. Thoughts? > > Thanks, > Nick > >> Subject: Re: approach for defining loggers >> From: ralph.go...@dslextreme.com

Re: approach for defining loggers

ailed diagnosis. Those could be > turned off totally without having much impact on system management. The > same can't be said for FATAL to INFO. These levels should always be on so > that you can properly manage the system. > > Thanks, > Nick > > > Date: Mon, 31 Aug 2

RE: approach for defining loggers

? Thanks, Nick > Date: Mon, 31 Aug 2015 15:02:09 -0700 > Subject: Re: approach for defining loggers > From: garydgreg...@gmail.com > To: log4j-user@logging.apache.org > > I think of levels as "how important is this" and "who needs to know this". > Some

Re: approach for defining loggers

e from > logging these trace events on or off, unless you also required they use > these markers or some other mechanism. I would rather each use their own > logger and if we find we're getting a bunch of garbage from all org.foobar > components they we can turn them all off. > >

Re: approach for defining loggers

ggers to log different levels do you? >> > > No separate loggers per levels. > > Gary > > >> >> Thanks, >> Nick >> >> > Date: Mon, 31 Aug 2015 15:02:09 -0700 >> > Subject: Re: approach for defining loggers >> > From: garydgreg

RE: approach for defining loggers

flow through ETW and end up in log files which are then Ftp'd to a central location. Thanks, Nick > Date: Mon, 31 Aug 2015 15:38:55 -0700 > Subject: Re: approach for defining loggers > From: garydgreg...@gmail.com > To: log4j-user@logging.apache.org > > All of this makes me

Re: approach for defining loggers

nks, > Nick > >> Date: Mon, 31 Aug 2015 15:02:09 -0700 >> Subject: Re: approach for defining loggers >> From: garydgreg...@gmail.com >> To: log4j-user@logging.apache.org >> >> I think of levels as "how important is this" and "who needs to kn

RE: approach for defining loggers

Your example sounds reasonable. Thanks, Nick > Subject: Re: approach for defining loggers > From: remko.po...@gmail.com > Date: Tue, 1 Sep 2015 07:57:57 +0900 > To: log4j-user@logging.apache.org > > Not sure that I understand your use case, so let me give a concrete examp

RE: approach for defining loggers

And I agree. Just letting you know I'm not a total noob when it comes to logging, just log4j and log4net are new to me. Thanks, Nick > Date: Mon, 31 Aug 2015 15:56:40 -0700 > Subject: Re: approach for defining loggers > From: garydgreg...@gmail.com > To: log4j-user@loggin

Re: approach for defining loggers

On Aug 29, 2015, at 7:44 PM, Nicholas Duane nic...@msn.com wrote: I'm curious if there is a prescribed approach to defining loggers. Let me state what my assumption is. I assume that normally if some piece of code wants to log events/messages that it should create a logger for itself.