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 example
> of how I use loggers.
>
> At work I have a component that is responsible for handling marketdata.
> This component has two loggers: one that uses the component class name as its
> name, another called "RAW_FEED". The first logs stuff about initialization
> and for example when another component subscribes to market data. The second
> (RAW_FEED) one logs every market data event as it comes off the wire to a
> separate file (via a separate appender).
>
> This allows us to switch the RAW_FEED off on some systems and on on others.
>
> I suggest you simply do what achieves your goals. If there are multiple
> options then choose the one that is easiest for your team to maintain.
>
> Sent from my iPhone
>
> > On 2015/09/01, at 7:07, Nicholas Duane <nic...@msn.com> wrote:
> >
> > All sounds reasonable to me. I'm not sure any of the statements you made
> > go against anything I have stated. Please let me know if you think
> > otherwise.
> >
> > In your authentication module, you log all levels through its logger,
> > right? You don't use separate loggers to log different levels 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".
> >> Some of the art of logging is deciding who you audience is. To help your
> >> development team chase down a bug, you want to make sure that the app logs
> >> interesting events at the DEBUG and TRACE level. This is different that
> >> "what it is I am telling this audience", which is where I use loggers. To
> >> tell who comes in and out of the system, I have logging in the
> >> authentication module. To tell what kind of SQL goes to the database, I
> >> have DEBUG logging in my DB interface code.
> >>
> >> I think that once you start chasing down issues and bugs, and writing code
> >> to help you do that, then it might become more obvious, as to what to do.
> >>
> >> Gary
> >>
> >>> On Mon, Aug 31, 2015 at 2:51 PM, Nicholas Duane <nic...@msn.com> wrote:
> >>>
> >>> I did look through a bit of documentation on markers:
> >>>
> >>> https://logging.apache.org/log4j/2.0/manual/markers.html
> >>>
> >>> http://stackoverflow.com/questions/16813032/what-is-markers-in-java-logging-frameworks-and-that-is-a-reason-to-use-them
> >>>
> >>> My initial impression is that I don't want to use markers. What I'd like
> >>> to be able to say is:
> >>>
> >>> "log the way you have been logging in the past. You don't need to know
> >>> about any special loggers. Use your own. Here is a new level for our new
> >>> type of "event". Use that to log this new event."
> >>>
> >>> I guess I'm not understanding your vernacular in terms of levels. In my
> >>> mind the different levels also define different "types" of events. For
> >>> instance, DEBUG and less specific I would see as tracing type events which
> >>> are non-functional in nature. They are purely for understanding the call
> >>> flow, or for performance gathering, or detailed 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 2015 08:37:25 -0700
> >>>> Subject: Re: approach for defining loggers
> >>>> From: garydgreg...@gmail.com
> >>>> To: log4j-user@logging.apache.org
> >>>>
> >>>> Hi Nick,
> >>>>
> >>>> Creating a single new level is seldom the right solution IMO. It's not
> >>> like
> >>>> you are missing a level of granularity (we have custom level examples
> >>> that
> >>>> demonstrate that, like a VERBOSE level that sits between INFO and DEBUG).
> >>>> It sounds like you need to use _hierarchical_ loggers and/or markers.
> >>>>
> >>>> The fact that the level is called BUSINESS is also a hint that a level is
> >>>> not quite right because it does not fit in the Level vernacular (INFO,
> >>>> WARN, and so on).
> >>>>
> >>>> If you needed a different set of levels, that would be another story
> >>> (like
> >>>> the DEFCON levels example).
> >>>>
> >>>> Gary
> >>>>
> >>>>> On Mon, 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
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> 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
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
>
