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

[Remko Popma (JIRA)]

Remko Popma created LOG4J2-321:
----------------------------------

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

[Remko Popma (JIRA)]

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

Remko Popma commented on LOG4J2-321:
------------------------------------

From: Ralph Goers
To: Log4J Developers List <log4j-***@logging.apache.org>
Sent: Wednesday, July 24, 2013 7:57 AM
Subject: Re: Config additions, WAS: Confused: want low latency: do I need BOTH async logger AND async appender??

I think I just came up with another attribute for the JMX element. I'll have to look at the status logger but I believe it is always creating a StatusData object and putting it in a ring buffer so they can be printed later. This will actually create a lot of objects and will impact performance. So we will want to add a statusLevel attribute to the JMX element to specify what the level is on the events that should be added to the buffer.

It was actually kind of cool though as the person doing the performance test looked at the JMX stats and even though the status was set to error in the configuration they had lots of debug messages in JMX that were quite helpful to verify a misconfiguration.

Ralph

Post by Remko Popma (JIRA)
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.
* 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?
* 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

[Remko Popma (JIRA)]

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

Remko Popma commented on LOG4J2-321:
------------------------------------

Proposed sample configuration:
{code}
<configuration level="warn"
Log4jContextSelector="org.apache.logging.log4j.core.async.AsyncLoggerContextSelector">
<AsyncLoggers exceptionHandler="my.custom.Handler" ringBufferSize="128" waitStrategy="Block" />
<jmx enabled="true" />
<appenders>
...
</appenders>
<loggers>
...
</loggers>
</configuration>
{code}

I'm actually not sure if {{AsyncLoggers}} should be a separate element. It looks confusingly similar to the {{loggers}} element...

Post by Remko Popma (JIRA)
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.
* 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?
* 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

[Nick Williams (JIRA)]

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

Nick Williams commented on LOG4J2-321:
--------------------------------------

I do think {{AsyncLoggers}} should be a separate element. But perhaps something less confusing like {{AsyncLoggerConfig}}?

The {{Log4jContextSelector}} attribute should start with a lowercase letter. However, I think a name like that is simply too long and unnecessary. {{contextSelector}} seems more appropriate.

Post by Remko Popma (JIRA)
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.
* 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?
* 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

[Remko Popma (JIRA)]

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

Remko Popma commented on LOG4J2-321:
------------------------------------

I don't like the additional element. At the moment there is a hierarchy in the configuration: {{configuration}} encapsulates all and contains global attributes that pertain to all elements. Inside configuration there is an {{appenders}} and a {{loggers}} section. These are independent of each other unless they are linked with a {{-ref}} element. This is all very clean and intuitive. For illustration purposes, the basic skeleton looks like this:

{code}
<configuration>
<appenders>
..
</appenders>
<loggers>
..
</loggers>
</configuration>
{code}

I think keeping all global settings in the {{<configuration>}} element should be preferred because these settings apply to everything in the config.

Introducing a new element just because some attributes are related is confusing and raises all kinds of questions for our users, for example: _I understand what loggers and appenders do, but what is a jmx? Can I have more than one? Do I need to hook it to one of my loggers with a jmx-ref element? And what about the AsyncLoggerConfig element, does this relate to {{<asyncRoot>}}? Does it need a ref? Do I need a separate {{<AsyncLoggerConfig>}} element for each {{<asyncLogger>}}?_

Post by Remko Popma (JIRA)
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.
* 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?
* 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

[Ralph Goers (JIRA)]

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

Ralph Goers commented on LOG4J2-321:
------------------------------------

Not that we have to copy it, but you can look at http://logback.qos.ch/manual/jmxConfig.html and see how Logback handles JMX configuration. I think your points are valid though. If it is just jmx=disabled|enabled on the configuration element then that would be fine. But if it also contains jmxStatusLevel=level then I'm not so sure.

Post by Remko Popma (JIRA)
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.
* 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?
* 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

[Remko Popma (JIRA)]

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

Remko Popma commented on LOG4J2-321:
------------------------------------

I created a separate Jira ticket (LOG4J2-324) for the StatusLogger performance improvement mentioned above.

Post by Remko Popma (JIRA)
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.
* 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?
* 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

[Remko Popma (JIRA)]

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

Remko Popma commented on LOG4J2-321:
------------------------------------

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?

Post by Remko Popma (JIRA)
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.
* 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?
* 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

[Remko Popma (JIRA)]

[ 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: ***@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?

Post by Remko Popma (JIRA)
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.
* 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?
* 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

[Remko Popma (JIRA)]

[ 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: ***@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?

Post by Remko Popma (JIRA)
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.
* 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?
* 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

[Remko Popma (JIRA)]

[ https://issues.apache.org/jira/browse/LOG4J2-321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Remko Popma reassigned LOG4J2-321:
----------------------------------

Assignee: Remko Popma

Post by Remko Popma (JIRA)
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.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.
* 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?
* 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

[Gary Gregory (JIRA)]

[ https://issues.apache.org/jira/browse/LOG4J2-321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gary Gregory updated LOG4J2-321:
--------------------------------

Fix Version/s: (was: 2.0-beta9)
2.0-rc1

Post by Remko Popma (JIRA)
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.0-rc1
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.
* 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?
* 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.1#6144)

[Matt Sicker (JIRA)]

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

Matt Sicker commented on LOG4J2-321:
------------------------------------

In general, I think the class used to fetch property values should be replaceable. For instance, in OSGi, instead of directly using System.getProperty(), you would use [BundleContext.getProperty|http://www.osgi.org/javadoc/r4v43/core/org/osgi/framework/BundleContext.html#getProperty(java.lang.String)]. Although, I think that using System.getProperty will automagically use the BundleContext (which I think was introduced after the original OSGi specification).

Then there's obtaining the same properties via the ServletContext.getInitParameter(). Or what about javax.batch JobContext.getProperties? Or using JNDI?

Or should this all be using ContextSelector?

Post by Remko Popma (JIRA)
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.0-rc1
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.
* 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?
* 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)

[Remko Popma (JIRA)]

[ https://issues.apache.org/jira/browse/LOG4J2-321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Remko Popma updated LOG4J2-321:
-------------------------------

Fix Version/s: (was: 2.0-rc1)
2.1

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">}}.

Post by Remko Popma (JIRA)
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.
* 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?
* 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)

[Remko Popma (JIRA)]

[ 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: ***@yahoo.com):
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">}}.

Post by Remko Popma (JIRA)
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.
* 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?
* 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)

[Remko Popma (JIRA)]

[ https://issues.apache.org/jira/browse/LOG4J2-321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Remko Popma updated LOG4J2-321:
-------------------------------
Fix Version/s: (was: 2.1)
2.2

Post by Remko Popma (JIRA)
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.2
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.
* 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?
* 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.3.4#6332)