The bottom line is it doesn’t matter which log level they use. With the
configuration below ALL business events will be accepted, meaning the log level
on the logger will not be checked. Then every logger would have a marker
filter to accept or deny the event
<Configuration>
<MarkerFilter marker=“Business” onMatch=“ACCEPT” onMisMatch=“NEUTRAL”/>
<Appenders>
<File name=“business” fileName=“business.log”>
<PatternLayout pattern=“%d %p %c{1.} [%t] %m%n/>
</File>
<Console name=“STDOUT” target=“SYSTEM_OUT”>
<PatternLayout pattern=“%d %p %c{1.} [%t] %m%n/>
</Console>
</Appenders>
<Loggers>
<Root level=“warn”>
<AppenderRef ref=“business”>
<MarkerFilter marker=“Business” onMatch=“ACCEPT” onMisMatch=“DENY”/>
</AppenderRef>
<AppenderRef ref=“STDOUT”>
<MarkerFilter marker=“Business” onMatch=“DENY” onMisMatch=“NEUTRAL”/>
</AppenderRef>
</Root>
</Loggers>
</Configuration>
If you tell them to use a “special” logger you can do the following, which is a
bit simpler. All the events are accepted and passed to the business logger. The
level is ignored so you don’t need to even specify it. All events on that
logger will be passed to the business appender.
<Configuration>
<MarkerFilter marker=“Business” onMatch=“ACCEPT” onMisMatch=“NEUTRAL”/>
<Appenders>
<File name=“business” fileName=“business.log”>
<PatternLayout pattern=“%d %p %c{1.} [%t] %m%n/>
</File>
<Console name=“STDOUT” target=“SYSTEM_OUT”>
<PatternLayout pattern=“%d %p %c{1.} [%t] %m%n/>
</Console>
</Appenders>
<Loggers>
<Logger name=“BUSINESS” additvity=“false”>
<AppenderRef ref=“business”/>
</Logger>
<Root level=“warn”>
<AppenderRef ref=“STDOUT”/>
</Root>
</Loggers>
</Configuration>
If you want users to not specify an event then just create your own
ExtendedLogger using the ExtendedLoggerWrapper and then implement a method such
as
logBusiness(msg)
or similar. That would use the logMessage method.
Ralph
> On Sep 8, 2015, at 7:44 PM, Nicholas Duane <nic...@msn.com> wrote:
>
> 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
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org
