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<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 >> > >
