Let's say we have a schema where one of the properties is "category". "category" could be "info", "warn", "business", "audit", etc. I could use that property to forward the events to the appropriate places. We don't have that property because I guess we don't think we need it. The current thinking is that level will tell us whether an event is a business event or some other type of event.
The problem with: logger.info(BUSINESS, msg) is that you could also do: logger.debug(BUSINESS, msg); logger.fatal(BUSINESS, 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 defining loggers > From: ralph.go...@dslextreme.com > Date: Tue, 8 Sep 2015 19:24:32 -0700 > To: log4j-user@logging.apache.org > > 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 >
