There are actually 2 levels which is probably why this is so confusing. One applies to the status logger, which is only used when there are no listeners and controls what is saved in the buffer. The second is for the status console listener, which filters what should be written to the console from the buffer and the incoming events using its level.
From what you are saying it does seem the third property is unnecessary. Ralph > On May 3, 2014, at 2:20 AM, Remko Popma <[email protected]> wrote: > > While documenting the system properties I found there are three(!) system > properties related to the default status logger level. > And they all have a different default value... > > 1. log4j2.StatusLogger.level (default: WARN) - the StatusLogger level > 2. Log4jDefaultStatusLevel (default: ERROR) - used in AbstractConfiguration > to determine the default status level. Via the StatusConfiguration class this > sets up a StatusConsoleListener with the configured level. > 3. org.apache.logging.log4j.StatusLevel (default: FATAL) - If a > StatusConsoleListener is constructed without a level it uses this system > property to set a level. > > Is this not a bit too much? I would like to document all system properties > but this is confusing. > > Does anyone mind if I remove the (unused) default constructor for > StatusConsoleListener, which makes the "org.apache.logging.log4j.StatusLevel > (default: FATAL)" system property unnecessary? > > > > >> On Sat, May 3, 2014 at 2:58 PM, Remko Popma <[email protected]> wrote: >> Currently the documentation for the {{log4j.Clock}} system property is in >> the Async Logger page. >> If we make this a general, log4j-wide, system property then the >> documentation for this property should be in a more central location. >> >> If nobody objects, I will add a "System Properties" section to the >> Configuration manual page. >> This section will list all system properties that can be used to modify >> Log4j's behaviour. This includes the {{log4j.Clock}} property, but I will >> look through the code and the docs and try to make it a complete list. >> >> Let me know if there are certain system properties that you *don't want* to >> appear in that list for any reason. >> >> >> >>> On Fri, May 2, 2014 at 11:04 PM, Gary Gregory <[email protected]> >>> wrote: >>>> On Thu, May 1, 2014 at 7:27 PM, Remko Popma <[email protected]> wrote: >>>> ASAIKS, there are currently only two places that use >>>> System.currentTimeMillis() for creating the log event timestamp: >>>> * one of the Log4jLogEvent constructors >>>> * PatternProcessor#formatFileName - the log event created here is a >>>> temporary object used only by the StrSubstitutor >>>> >>>> Not 100% sure about the PatternProcessor#formatFileName... Use >>>> configurable time or system time here? >>> >>> I think so based on the user story right? As a user, I want to simulate a >>> different time on the system, so that timestamps in the log are determined >>> by my custom clock. I would assume that includes timestamps is other >>> artifacts like file names. >>> >>> It would be good to hear back from the user here. >>> >>> Gary >>> >>>> >>>> >>>> >>>>> On Fri, May 2, 2014 at 8:11 AM, Remko Popma <[email protected]> wrote: >>>>> In recent Jira ticket LOG4J2-628 "Cannot set log4j.Clock with Async >>>>> appender", the user requests that all log event timestamps are generated >>>>> from the a configurable Clock. Currently only log event timestamps >>>>> generated by Async Loggers are configurable. >>>>> >>>>> I think it makes sense to do this. >>>>> I propose to limit the scope of Clock to log event timestamps only. >>>>> I don't propose to use the Clock internally for things like thread >>>>> timeouts. >>>>> >>>>> Thoughts? >>>>> >>>>> Remko >>> >>> >>> >>> -- >>> E-Mail: [email protected] | [email protected] >>> Java Persistence with Hibernate, Second Edition >>> JUnit in Action, Second Edition >>> Spring Batch in Action >>> Blog: http://garygregory.wordpress.com >>> Home: http://garygregory.com/ >>> Tweet! http://twitter.com/GaryGregory >
