Android is not the center of the universe though. You omitted the "ASSERT" level, which is totally weird.
Gary On Thu, Sep 17, 2015 at 7:58 AM, Mikael Ståldal <mikael.stal...@magine.com> wrote: > Android have these levels ( > http://developer.android.com/reference/android/util/Log.html): > > ERROR > WARN > INFO > DEBUG > VERBOSE > > Adding VERBOSE above DEBUG would be inconsistent with Android and thus > confusing. > > On Thu, Sep 17, 2015 at 12:24 AM, Gary Gregory <garydgreg...@gmail.com> > wrote: > > > At first I was going to strongly recommend against using a custom level > > called BUSINESS. Custom levels have been a problem in the past at my work > > (IMO). Markers are really a perfect fit for this use-case. That got me to > > thinking about my previous idea on this of adding more levels to Log4j. > > Please bear with me. Today we have: > > > > OFF > > FATAL > > ERROR > > WARN > > INFO > > DEBUG > > TRACE > > ALL > > > > What I could use today are *these* levels too: > > > > OFF > > *EXIT* > > FATAL > > ERROR > > WARN > > *HEADLINE* > > INFO > > *VERBOSE* > > DEBUG > > TRACE > > ALL > > > > (EXIT is called when you System.exit(), which might not be loggable > > depending on I don't know what, HEADLINE is a lame name but I can't think > > of anything better, VERBOSE is obvious IMO) > > > > Which made me wonder if your BUSINESS level could fit in like this: > > > > OFF > > FATAL > > ERROR > > WARN > > *BUSINESS* > > INFO > > DEBUG > > TRACE > > ALL > > > > So maybe, just maybe, I could see that a BUSINESS level makes sense > instead > > of a marker. > > > > Gary > > > > > > On Wed, Sep 16, 2015 at 2:34 PM, Nicholas Duane <nic...@msn.com> wrote: > > > > > I was hoping on getting some replies to my last message as I'm trying > to > > > figure out the best way to utilize the existing logging frameworks, > > > log4j(2) and log4net in our case, to log our business events and ensure > > the > > > business events flow to the correct destination. > > > > > > I think the two main suggestions were to either use markers or a > separate > > > "well known" logger. > > > > > > As I mentioned in the previous message, I was about to write a sample > > > which used markers just to better understand how they work. The first > > road > > > block I ran into is that log4net does not support markers, as far as I > > can > > > tell. Now the implementation doesn't have to be the same on both > windows > > > and linux, but that would certainly be a plus if it was. Also, it > > doesn't > > > look like markers have been heavily adopted by many logging frameworks. > > > The one article I read only listed log4j2 and logback. > > > > > > In addition, while markers seem like they would be better at indicating > > > the type or category of event as opposed to using a level, you still > have > > > to define a marker for each type I guess. I could either define a > custom > > > level or a custom marker. Since markers are not available in log4net > and > > > custom levels are, a custom level might work out better for us. > > > > > > Using a "well known" logger to log business events seems like a > > reasonable > > > approach. And while I don't see any major downsides with going this > > route, > > > it seems that a piece of code which is logging using their own logger > > > should be able to log a business event with that same logger. It was > > > stated previously that the level indicates the importance of the event > > and > > > the logger indicates the types of events, or why someone might want to > > look > > > at the events. The example given was some market data code which used > > its > > > own logger to log market data information. That seems totally > > reasonable, > > > however, it doesn't seem to fit my example. In our case any component > > can > > > emit a business event. > > > > > > I then thought that maybe I could use the EventLogger, which I think > > > someone might have mentioned along the way. I was hoping to try that > out > > > also, assuming that allowed me to pass a marker in whatever methods it > > > exposed. However, I only see a static marker property on the > EventLogger > > > class. > > > > > > The other option which I'm considering is exposing a property on my > event > > > object which indicates the category of event. At the moment I have a > > > "type" property which, of course, indicates the event type. However, > > this > > > will be different for every different business event and thus I need > > > another property which tells me that the event is a "business" event. > > Then > > > I was thinking I could write a filter which checks the message object > to > > > see if it's one of my events and if so use the "category" to forward to > > the > > > appropriate destination. > > > > > > Am I missing any other viable solutions? > > > > > > Thanks, > > > Nick > > > > > > > From: nic...@msn.com > > > > To: log4j-user@logging.apache.org > > > > Subject: markers > > > > Date: Tue, 15 Sep 2015 22:25:37 -0400 > > > > > > > > > > > > > > > > > > > > I was about to starting writing a sample to see how markers work and > to > > > see if they could be used for logging business events instead of using > a > > > custom level. While I might have mentioned log4net in passing, we're > > > trying to capture these business events using existing logging > > frameworks. > > > The thinking is that we'd use log4net on windows and log4j(2) on linux > > (no > > > facade). Ideally the design would be similar across both platforms. > > That > > > being said, I'm surprised at how different log4net is from log4j(2). > It > > > appears log4net doesn't support markers. While we don't have to have > the > > > same solution for both platforms, it would be nice if the solutions > were > > > the same or similar. > > > > > > > > I also looked at the EventLogger and that class doesn't have any > > > overloads which take a marker, just a static marker property. I guess > > the > > > EventLogger can be assigned only a single marker? > > > > > > > > Thanks, > > > > Nick > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > 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
