You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by "Remko Popma (JIRA)" <ji...@apache.org> on 2013/08/14 16:42:48 UTC

[jira] [Comment Edited] (LOG4J2-321) Provide configuration alternative to system properties

    [ https://issues.apache.org/jira/browse/LOG4J2-321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13739726#comment-13739726 ] 

Remko Popma edited comment on LOG4J2-321 at 8/14/13 2:41 PM:
-------------------------------------------------------------

About the Log4jContextSelector, is it possible to make this configurable from the config file?

This is the order in which relevant objects are instantiated:
# LogManager (static block): instantiates a LoggerContextFactory implementation.
# Log4jContextFactory is the default (core) implementation.
# In the Log4jContextFactory constructor the ContextSelector is instantiated.
#*  (based on the value of system property "Log4jContextSelector" or default ClassLoaderContextSelector).
# All Log4jContextFactory#getContext methods delegate to the selector.
# The first time a LogContext is returned, the Log4jContextFactory will call LogContext#start on it, which will trigger a reconfiguration (and reads the config file).

This may be more difficult than I thought...
Thoughts?
                
      was (Author: remkop@yahoo.com):
    About the Log4jContextSelector, is it possible to make this configurable from the config file?

This is the order in which relevant objects are instantiated:
LogManager (static block): instantiates a LoggerContextFactory implementation.
Log4jContextFactory is the default (core) implementation.
In the Log4jContextFactory constructor the ContextSelector is instantiated.
  (based on the value of system property "Log4jContextSelector" or default ClassLoaderContextSelector).
All Log4jContextFactory#getContext methods delegate to the selector.
The first time a LogContext is returned, the Log4jContextFactory will call LogContext#start on it, which will trigger a reconfiguration (and reads the config file).

This may be more difficult than I thought...
Thoughts?
                  
> Provide configuration alternative to system properties
> ------------------------------------------------------
>
>                 Key: LOG4J2-321
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-321
>             Project: Log4j 2
>          Issue Type: Bug
>    Affects Versions: 2.0-beta8
>            Reporter: Remko Popma
>             Fix For: 2.0-beta9
>
>
> Some components behaviour cannot be configured in the configuration file but only with System properties. There is a strong preference to ensure all behaviour can be configured in the configuration file.
> Properties that can be used to configure AsyncLoggers when all loggers are Async:
> * Log4jContextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector
> * AsyncLogger.ExceptionHandler
> * AsyncLogger.RingBufferSize
> * AsyncLogger.WaitStrategy
> * log4j.Clock - currently only used for timestamping RingBufferLogEvents. 
> Question: Should all LogEvents use this clock?
> The following system properties can be used to configure mixed Async Loggers:
> * AsyncLoggerConfig.ExceptionHandler	
> * AsyncLoggerConfig.RingBufferSize
> * AsyncLoggerConfig.WaitStrategy
> For JMX there is only the one "disable" property, in the mailing list it was suggested to make this into an element rather than an attribute to future-proof it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org