[ 
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:51 PM:
-------------------------------------------------------------

About the Log4jContextSelector, is it even possible to make this configurable 
from the config file? The config file isn't read until some time after the 
ContextSelector is created, and the path to reading the config file goes 
through the selector instance...

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: rem...@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-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Reply via email to