On Fri, Sep 11, 2015 at 1:36 PM, Ralph Goers <ralph.go...@dslextreme.com>
wrote:

> See below
>
> > On Sep 11, 2015, at 12:33 PM, Nicholas Duane <nic...@msn.com> wrote:
> >
> > I think it's great that you took the time and effort to put this
> together.  Hopefully it will help guide people in the correct direction as
> they work through these issues.  Hopefully this link is found when they
> google 'log4j log levels' or 'log4j loggers' etc..
> >
> > 1. While your level examples elude to this you don't, as far as I can
> tell, specifically spell this out.  I guess you're always assuming that
> level is a gradient or scale.  Meaning if I turn on a specific level I will
> get events for that level and any level more specific.  Would it be invalid
> to make level an enumeration and thus level would 'kind of' indicate event
> 'type’.
>

Yes, it would be invalid. Sadly, I must not have explained markers clearly
enough, because markers do indicate an event's "type" as you call it. The
event "types" could be specified as an enumeration if you so desired.


>
> All Java logging frameworks that I am aware of view the level as a
> gradient as Gary described it.  If you look at RFC 3164 [1] you will see
> that unix syslog events have a severity that works exactly the same way.
> This is actually where Java logging levels were inspired from. If you look
> at the documentation for syslog [2] you will see mention that this is the
> way it works on unix systems.


> >
> > 2. Wording problems maybe:
> >
> > "What if others log from a third party library log"
>

Thank you for catching that. I changed this to: "What if doors from a third
party library log this kind of event at TRACE, another twist!"


> >
> > "Now, I can configure Log4j to log only all events"
>

Changed to: "Now, I can configure Log4j to log only events that contain the
marker DOOR."


> >
> > 3. In the part about markers you indicate that with a marker you can
> enable logging for an event no matter what level the event was logged at.


I can see the confusion. The level rules the roost, so if that level is not
enabled, the event will not be logged.

This updated text I hope will help:

"No new loggers needed, just an additional parameter to your log call,
<em>regardless</em> of the level API used.

Now, I can configure Log4j to log only events that contain the marker DOOR
(if that level is enabled)."

Gary


> In that case the below statement seems to contradict:
> >
> > "Here, start by setting the root logger to WARN, then we set the oven to
> > log at DEBUG because the oven logs door events at the DEBUG level, and
> > the garage to log at INFO because the garage logs door events at the
> > INFO level."
> >
> > I thought it shouldn't matter if the over door logs at DEBUG level.
> Can't I still set everything to WARN and use a marker to get the event
> logged?
>
> You can do both.  If you choose to ignore the marker then you can filter
> only by log level.  If you want one appender to handle all the BUSINESS
> events and another appender to handle only warnings and errors (including
> BUSINESS events) you can also do that.  See the configuration I sent you
> the other day. It only separates between those with the marker and those
> without because that is what you asked for. However, I could have given you
> a configuration that also does the second case.
>
> >
> > 4. Your markers section seems geared 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.
>
> You should be able to extrapolate from the configuration I provided 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: Thu, 10 Sep 2015 21:21:09 -0700
> >> Subject: Re: approach for defining loggers
> >> From: garydgreg...@gmail.com
> >> To: log4j-user@logging.apache.org
> >>
> >> This thread inspired me to explain logging concepts:
> >>
> >>
> https://garygregory.wordpress.com/2015/09/10/the-art-of-test-driven-development-understanding-logging/
> >>
> >> I hope it helps!
> >>
> >> Gary
> >>
> >> On Wed, Sep 9, 2015 at 12:47 AM, Mikael Ståldal <
> mikael.stal...@magine.com>
> >> wrote:
> >>
> >>> 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 <nic...@msn.com> 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
> business
> >>>> 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: garydgreg...@gmail.com
> >>>>> To: log4j-user@logging.apache.org
> >>>>>
> >>>>> Or
> >>>>> Logger logger = LogManager.getLogger("Business");
> >>>>> ...
> >>>>> logger.info("Hello");
> >>>>>
> >>>>> Gary
> >>>>>
> >>>>> On Tue, Sep 8, 2015 at 7:24 PM, Ralph Goers <
> >>> ralph.go...@dslextreme.com>
> >>>>> wrote:
> >>>>>
> >>>>>> Can you please clarify, “If we had some way to know an event is a
> >>>> business
> >>>>>> event we wouldn’t need level”?  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 <nic...@msn.com> 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 schema
> >>> we
> >>>>>> come up with for a business event.  While an instance of this schema
> >>>> 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
> the
> >>>>>> event, 'business' being one such category.  Instead we were thinking
> >>> 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
> 'business'
> >>>>>> events to yet another store.  For 'trace' and 'info' - 'fatal' it
> >>> seems
> >>>>>> reasonable to filter on level within the appender to get those
> events
> >>>> to
> >>>>>> the appropriate location.  It seemed reasonable to do something
> >>>> similar for
> >>>>>> 'business'.
> >>>>>>>
> >>>>>>> I also looked into the EventLogger but not sure that's appropriate.
> >>>> For
> >>>>>> one we lose the granularity to control a specific piece of code from
> >>>>>> 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
> 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
> >>>>>>>> Subject: Re: approach for defining loggers
> >>>>>>>> Date: Mon, 7 Sep 2015 20:39:11 -0700
> >>>>>>>> To: log4j-user@logging.apache.org
> >>>>>>>>
> >>>>>>>> I still don’t understand why you don’t 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 why
> >>>> it is
> >>>>>> NOT a level. IOW, it gives you a second dimension for filtering.
> Ceki
> >>>>>> invented Markers when he created SLF4J. For his point of view see
> >>>>>>
> >>>>
> >>>
> http://stackoverflow.com/questions/16813032/what-is-markers-in-java-logging-frameworks-and-that-is-a-reason-to-use-them
> >>>>>> <
> >>>>>>
> >>>>
> >>>
> http://stackoverflow.com/questions/16813032/what-is-markers-in-java-logging-frameworks-and-that-is-a-reason-to-use-them
> >>>>>>> .
> >>>>>>>>
> >>>>>>>> Ralph
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> On Sep 7, 2015, at 5:54 PM, Nicholas Duane <nic...@msn.com>
> >>> 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 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
> >>>>>>>>>
> >>>>>>>>>> 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 importance. That is why there
> >>> is a
> >>>>>> hierarchy. If you want informational messages then you also would
> >>> want
> >>>>>> warnings and errors.
> >>>>>>>>>>
> >>>>>>>>>> “BUSINESS” does not convey the same meaning.  Rather, it is some
> >>>> sort
> >>>>>> of category, which is what Markers are for.
> >>>>>>>>>>
> >>>>>>>>>> Using the class name as the logger name is a convention. If you
> >>>>>> 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
> have
> >>>>>> 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
> routed
> >>>> 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 categorize
> >>>>>> logging events by arbitrary attributes.
> >>>>>>>>>>
> >>>>>>>>>> Ralph
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> On Aug 31, 2015, at 8:10 AM, Nicholas Duane <nic...@msn.com>
> >>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> Thanks for the feedback.  I will look into Markers and MDC.
> >>>>>>>>>>>
> >>>>>>>>>>> With respect to using a separate logger, it would seem I would
> >>>> lose
> >>>>>> the information about what application code, eg. the class logger,
> is
> >>>>>> sourcing the event.  We would like to have this information.  On top
> >>> of
> >>>>>> that, it seems odd, maybe to me only, that for this new level we
> have
> >>>> 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
> 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 then
> >>>> filter 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
> >>>>>>>>>>>> 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 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 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, someone
> >>>>>> suggested that we could also create a separate logger for this
> event.
> >>>> My
> >>>>>> thinking is that while we don't ever want to turn off logging of
> this
> >>>>>> event, loggers represent "event sources", e.g the code raising the
> >>>> events
> >>>>>> and thus having multiple different pieces of code use the same
> logger
> >>>>>> 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.
> Another
> >>>>>> approach is to use Markers.  Markers are somewhat hierarchical so
> you
> >>>> can
> >>>>>> use them for a variety of purposes.  If you look at how Log4j
> handles
> >>>> event
> >>>>>> logging it actually does both - it specifies EventLogger as the name
> >>>> 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 you
> >>> 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
> the
> >>>>>> RFC5424 format so that the event could have lots of key/value pairs
> >>> to
> >>>>>> identify the events.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Unfortunately, without knowing more details I don’t know that
> >>> I
> >>>> can
> >>>>>> give you a better idea on how I would implement it.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Ralph
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>>>>>>>> To unsubscribe, e-mail:
> >>>> log4j-user-unsubscr...@logging.apache.org
> >>>>>>>>>>>> For additional commands, e-mail:
> >>>> log4j-user-h...@logging.apache.org
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>> ---------------------------------------------------------------------
> >>>>>>>>>> To unsubscribe, e-mail:
> >>> log4j-user-unsubscr...@logging.apache.org
> >>>>>>>>>> For additional commands, e-mail:
> >>>> log4j-user-h...@logging.apache.org
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> >>>>>> For additional commands, e-mail: log4j-user-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
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> [image: MagineTV]
> >>>
> >>> *Mikael Ståldal*
> >>> Senior software developer
> >>>
> >>> *Magine TV*
> >>> mikael.stal...@magine.com
> >>> Regeringsgatan 25  | 111 53 Stockholm, Sweden  |   www.magine.com
> >>>
> >>> 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
> not
> >>> 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: 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

Reply via email to