logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicholas Duane <nic...@msn.com>
Subject RE: markers
Date Wed, 16 Sep 2015 21:34:58 GMT
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: nickdu@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
> 
> 
> 
>  		 	   		  
 		 	   		  
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message