[
https://issues.apache.org/jira/browse/LOG4J2-321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14060055#comment-14060055
]
Remko Popma edited comment on LOG4J2-321 at 7/16/14 12:12 AM:
--------------------------------------------------------------
It is not possible to define a ContextSelector in configuration because the
lifecycle needs the ContextSelector to be created before the configuration file
is read. So, to use AsyncLoggers without system properties, we need a way to
enable AsyncLoggers that uses the normal ContextSelector.
Currently LoggerContext defines a protected factory method {{newInstance(...)}}
to createLogger instances. AsyncLoggerContext overrides this method to create
AsyncLogger instances.
Instead of this factory method, LoggerContext should delegate this to a
separate factory object. This factory object can be derived from the
configuration. (Still need to work out the details...)
A sample config could look like this (all loggers async):
{code}
<configuration level="warn" jmxEnabled="true">
<appenders>
..
</appenders>
<AsyncLoggers asyncRingBufferSize="4096"
asyncWaitStrategy="Block"
asyncExceptionHandler="my.custom.Handler">
<root level="trace">
... (appender-refs here)
</root>
</AsyncLoggers>
</configuration>
{code}
Sample config 2 (mixed async/sync loggers):
{code}
<configuration level="warn" jmxEnabled="true">
<appenders>
..
</appenders>
<Loggers asyncRingBufferSize="128"
asyncWaitStrategy="Block"
asyncExceptionHandler="my.custom.Handler">
<Logger level="debug" name="my.sync.logger">
... (appender-refs here)
</Logger>
<AsyncLogger level="debug" name="my.async.logger">
...
</AsyncLogger>
<AsyncRoot level="trace">
...
</AsyncRoot>
</Loggers>
</configuration>
{code}
For the {{jmxEnabled}} attribute, an {{isJmxEnabled()}} method would need to be
added to the Configuration interface.
The enabled value may change when reconfigured, so the MBean registration logic
needs to be changed to first unregister the old MBeans, and then to check if
JMX is enabled in configuration before registering the new MBeans.
TBD:
What to do if the system property value conflicts with the configuration value?
For example:
{{-Dlog4j2.disable.jmx=true}} is set, but the configuration says
{{<configuration jmxEnabled="true">}}.
Similarly, which values to use when different values are specified for the
ringbuffer size (or other async logger options) in system properties than in
configuration.
was (Author: [email protected]):
It is not possible to define a ContextSelector in configuration because the
lifecycle needs the ContextSelector to be created before the configuration file
is read. So, to use AsyncLoggers without system properties, we need a way to
enable AsyncLoggers that uses the normal ContextSelector.
Currently LoggerContext defines a protected factory method {{newInstance(...)}}
to createLogger instances. AsyncLoggerContext overrides this method to create
AsyncLogger instances.
Instead of this factory method, LoggerContext should delegate this to a
separate factory object. This factory object can be derived from the
configuration. (Still need to work out the details...)
A sample config could look like this (all loggers async):
{code}
<configuration level="warn" jmxEnabled="true">
<appenders>
..
</appenders>
<!-- valid values for the async attribute are ALL, MIXED or NONE -->
<loggers async="ALL"
asyncRingBufferSize="4096"
asyncWaitStrategy="Block"
asyncExceptionHandler="my.custom.Handler">
<root level="trace">
... (appender-refs here)
</root>
</loggers>
</configuration>
{code}
Sample config 2 (mixed async/sync loggers):
{code}
<configuration level="warn" jmxEnabled="true">
<appenders>
..
</appenders>
<loggers async="MIXED"
asyncRingBufferSize="128"
asyncWaitStrategy="Block"
asyncExceptionHandler="my.custom.Handler">
<Logger level="debug" name="my.sync.logger">
... (appender-refs here)
</Logger>
<AsyncLogger level="debug" name="my.async.logger">
...
</AsyncLogger>
<AsyncRoot level="trace">
...
</AsyncRoot>
</loggers>
</configuration>
{code}
For the {{jmxEnabled}} attribute, an {{isJmxEnabled()}} method would need to be
added to the Configuration interface.
The enabled value may change when reconfigured, so the MBean registration logic
needs to be changed to first unregister the old MBeans, and then to check if
JMX is enabled in configuration before registering the new MBeans.
TBD:
What to do if the system property value conflicts with the configuration value?
For example:
{{-DLog4jContextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector}}
is set, but the configuration says {{<loggers async="NONE">}},
or {{-Dlog4j2.disable.jmx=true}} is set, but the configuration says
{{<configuration jmxEnabled="true">}}.
> 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
> Assignee: Remko Popma
> Fix For: 2.1
>
>
> 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 was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
