gory" 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
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 name, metho
; notion
>>> of flush time. The buffers are flushed when they become full or the
>> flush
>>> 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
>> even
that
> when
> > 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
> some
> > cases we have a 1:1 mapping from level to category, eg. compliance level
> ->
> >
eate 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
> some
> > cases we have a 1:1 mapping from level to category, eg. compliance level
> ->
> > compliance category. In some
pliance) 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
a marker.
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 apprecia
a
> definitive answer on what determines whether an event makes it to an
> appender?
>
What Ralph said.
Gayr
>
> Thanks,
> Nick
>
> > Date: Fri, 11 Sep 2015 16:46:14 -0700
> > Subject: Re: approach for defining loggers
> > From: garydgreg...@gmail.com
> &g
ender?
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
> wrote:
>
> >
> > > On Sep 1
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,
> > regardless of the level API used.
> >
> > Now, I can con
> 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 the marker DOOR
> (if that
I want to route specific types
> (/levels?) of events to specific appenders because different events are
> going to different locations.
>
> You should be able to extrapolate from the configuration I provided you to
> be able to do this.
>
> Ralph
>
>
>
> [1] https://w
vided you to be
able to do this.
Ralph
[1] https://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:
toward showing how to enable logging of
events even if the level 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,
Ni
> > 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 log
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
he 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 -0700
>&
y
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: garydgreg...@gmail.com
> To: log4j-user@logging.apache.org
&g
SINESS, msg);
logger.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 de
don't want to turn business logging 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.
> >
his is most likely a non-issue as I have mentioned that we
> don't want to turn business logging 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 compo
have
> mentioned that we don't want to turn business logging 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 distingu
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
> From: ralph.go...@dslextreme.com
>
I will certainly look them over again.
Thanks,Nick
Original message
From: Ralph Goers
Date: 09/07/2015 9:39 PM (GMT-07:00)
To: Log4J Users List
Subject: Re: approach for defining loggers
I still don’t understand why you don’t want to use Markers. They were designed
exactly
> 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
>
&
direct all 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
tal events 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:
ich 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: log4j-user@logging.apache.org
>
> A logging “Level” is a level of importan
e 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 -0700
> &g
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. However, maybe the EventLogger will
>> work.
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: garydgreg...@gmai
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: garydgreg...@gmail.com
> To: log4j-user@logging.apache.org
>
> On Mon, Aug 31,
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@l
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
; 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".
gt; 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 think we need docs for users new to logging...
> >
&g
t of the events 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
>
> A
>>
>
> 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...@gmail.com
>> > To: log4j-us
its logger,
> right?
Yes.
> You don't use separate loggers 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
> > Fr
n't turn certain sections of code 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
> compone
have separate loggers 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
els do you?
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".
and if we find we're
getting a bunch of garbage from all org.foobar components they we can turn them
all off.
Thanks,
Nick
> Subject: Re: approach for defining loggers
> From: ralph.go...@dslextreme.com
> Date: Mon, 31 Aug 2015 08:50:58 -0700
> To: log4j-user@logging.
d 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:
hey 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,
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
>>
<= 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: log4j-
ks,
Nick
> 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 wrote:
> >
> > I'm curious if there is a
> 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 normally if some piece of code
> wants to log events/messages that it should create a logger for itself. I
> guess
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. I
guess a reasonable name to use is the class name itself. In terms of l
50 matches
Mail list logo
