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.