rm5248 commented on PR #301: URL: https://github.com/apache/logging-log4cxx/pull/301#issuecomment-1827911747
Long-term we should maybe think about implementing markers like log4j2 does: https://logging.apache.org/log4j/2.x/manual/markers.html From Ralph Goers on Slack: > Well, if I had any idea what this PR actually does I might agree. The comments don’t make it obvious to me. Whatever it is doing, it seems like a hack. You should think of Logger levels as columns in a table whereas Markers are rows in the table. By this I mean that any event that occurs under a specifc Logger will be evaluated against the level associated wtih the logger. Makrers, on the other hand, cut across all Loggers. That is, if an event is logged with a Marker and there is a Filter defined for that Marker then that Filter MAY determine whether the event is logged. I say “may” because the logging level might be evaluated first, in which case the Marker filter will never be called. if the event is filtered by the level. Note that Markers can also be extremely useful for routing log events to different Appenders as well as identifying events that should be included in creating a dashboard. If log4cxx doesn’t support Markers I would add that before doing whatever is being proposed here. But also means you may need to extend how you currently perform filtering. Log4j allows filters to be specified in 4 different places. FWIW, Logback supports “Turbo Fitlers” which are just a Filter that is evaluated before anything else occurs and “regular” filters that can be configured on Appenders. Note that this means if you want to filter Markers both globally and on an Appender you have to implement 2 different filter classes. With Log4j it is just one. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
