[jira] [Commented] (LOG4J2-2072) Support TLS configuration through FlumeAppender
[ https://issues.apache.org/jira/browse/LOG4J2-2072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205995#comment-16205995 ] Matt Sicker commented on LOG4J2-2072: - Info about builders: https://logging.apache.org/log4j/2.x/manual/extending.html#Plugin_Builders If you find a way to abstract the plugin config for all three similar to what's done for the various OutputStream appenders for example, that'd be great as well. > Support TLS configuration through FlumeAppender > --- > > Key: LOG4J2-2072 > URL: https://issues.apache.org/jira/browse/LOG4J2-2072 > Project: Log4j 2 > Issue Type: Bug > Components: Flume Appender >Affects Versions: 2.9.1 >Reporter: Frank Swanson > > When using the FlumeAppnder with a FlumeAvroManager it would be nice to be > able to pass some properties through to the connect method for the RpcClient > to support SSL configuration. > The required properties to support the configuration are ~ > properties[0] = > Property.createProperty(RpcClientConfigurationConstants.CONFIG_TRUST_ALL_CERTS, > "false"); > properties[1] = > Property.createProperty(RpcClientConfigurationConstants.CONFIG_SSL, "true"); > properties[2] = > Property.createProperty(RpcClientConfigurationConstants.CONFIG_TRUSTSTORE, > path_to_truststore); > properties[3] = > Property.createProperty(RpcClientConfigurationConstants.CONFIG_TRUSTSTORE_PASSWORD, > super_secret); > properties[4] = > Property.createProperty(RpcClientConfigurationConstants.CONFIG_TRUSTSTORE_TYPE, > "JKS"); > I am happy to provide a PR for this feature if supported. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (LOG4J2-2072) Support TLS configuration through FlumeAppender
[ https://issues.apache.org/jira/browse/LOG4J2-2072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205976#comment-16205976 ] Gary Gregory edited comment on LOG4J2-2072 at 10/16/17 2:29 PM: IMO, the first task in this ticket should be to convert the factory method to a builder as we have for other appenders. was (Author: garydgregory): IMO, the first task in this ticket should be to convert the factory method to a builder as we have for other area of the project. > Support TLS configuration through FlumeAppender > --- > > Key: LOG4J2-2072 > URL: https://issues.apache.org/jira/browse/LOG4J2-2072 > Project: Log4j 2 > Issue Type: Bug > Components: Flume Appender >Affects Versions: 2.9.1 >Reporter: Frank Swanson > > When using the FlumeAppnder with a FlumeAvroManager it would be nice to be > able to pass some properties through to the connect method for the RpcClient > to support SSL configuration. > The required properties to support the configuration are ~ > properties[0] = > Property.createProperty(RpcClientConfigurationConstants.CONFIG_TRUST_ALL_CERTS, > "false"); > properties[1] = > Property.createProperty(RpcClientConfigurationConstants.CONFIG_SSL, "true"); > properties[2] = > Property.createProperty(RpcClientConfigurationConstants.CONFIG_TRUSTSTORE, > path_to_truststore); > properties[3] = > Property.createProperty(RpcClientConfigurationConstants.CONFIG_TRUSTSTORE_PASSWORD, > super_secret); > properties[4] = > Property.createProperty(RpcClientConfigurationConstants.CONFIG_TRUSTSTORE_TYPE, > "JKS"); > I am happy to provide a PR for this feature if supported. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2072) Support TLS configuration through FlumeAppender
[ https://issues.apache.org/jira/browse/LOG4J2-2072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205976#comment-16205976 ] Gary Gregory commented on LOG4J2-2072: -- IMO, the first task in this ticket should be to convert the factory method to a builder as we have for other area of the project. > Support TLS configuration through FlumeAppender > --- > > Key: LOG4J2-2072 > URL: https://issues.apache.org/jira/browse/LOG4J2-2072 > Project: Log4j 2 > Issue Type: Bug > Components: Flume Appender >Affects Versions: 2.9.1 >Reporter: Frank Swanson > > When using the FlumeAppnder with a FlumeAvroManager it would be nice to be > able to pass some properties through to the connect method for the RpcClient > to support SSL configuration. > The required properties to support the configuration are ~ > properties[0] = > Property.createProperty(RpcClientConfigurationConstants.CONFIG_TRUST_ALL_CERTS, > "false"); > properties[1] = > Property.createProperty(RpcClientConfigurationConstants.CONFIG_SSL, "true"); > properties[2] = > Property.createProperty(RpcClientConfigurationConstants.CONFIG_TRUSTSTORE, > path_to_truststore); > properties[3] = > Property.createProperty(RpcClientConfigurationConstants.CONFIG_TRUSTSTORE_PASSWORD, > super_secret); > properties[4] = > Property.createProperty(RpcClientConfigurationConstants.CONFIG_TRUSTSTORE_TYPE, > "JKS"); > I am happy to provide a PR for this feature if supported. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOGCXX-493) Documentation claiming `getTimeStamp` is in milliseconds but actually is in microseconds
[
https://issues.apache.org/jira/browse/LOGCXX-493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205886#comment-16205886
]
Vincent Thiery commented on LOGCXX-493:
---
Awesome! Thanks
> Documentation claiming `getTimeStamp` is in milliseconds but actually is in
> microseconds
>
>
> Key: LOGCXX-493
> URL: https://issues.apache.org/jira/browse/LOGCXX-493
> Project: Log4cxx
> Issue Type: Bug
> Components: Documentation
>Affects Versions: 0.10.0
>Reporter: Vincent Thiery
>Assignee: Thorsten Schöning
>Priority: Minor
> Labels: easyfix
> Fix For: 0.11.0
>
>
> The documentation implies that `getTimeStamp` returns a timesamp in
> *milliseconds*, see:
> {code:cpp}
> /** Return the timeStamp of this event. */
> inline log4cxx_time_t getTimeStamp() const
> { return timeStamp; }
> {code}
> and the member
> {code:cpp}
> /** The number of milliseconds elapsed from 1/1/1970 until logging event
> was created. */
> log4cxx_time_t timeStamp;
> {code}
> The problem is that in the constructor of `LoggingEvent`, the timestamp is
> filled with `apr_time_now()` that returns a timestamp in *microseconds*, see:
> {code:cpp}
> LoggingEvent::LoggingEvent(
> const LogString& logger1, const LevelPtr& level1,
> const LogString& message1, const LocationInfo& locationInfo1) :
>logger(logger1),
>level(level1),
>ndc(0),
>mdcCopy(0),
>properties(0),
>ndcLookupRequired(true),
>mdcCopyLookupRequired(true),
>message(message1),
>timeStamp(apr_time_now()),
>locationInfo(locationInfo1),
>threadName(getCurrentThreadName()) {
> }
> {code}
> When encountered, the issue is not difficult to debug, but it would be nice
> to correct the documentation.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (LOGCXX-361) 15-16 milliseconds granularity on Windows
[ https://issues.apache.org/jira/browse/LOGCXX-361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thorsten Schöning resolved LOGCXX-361. -- Resolution: Not A Problem log4cxx uses apr_time_now which provides microseconds on supported platforms. As mentioned in the comments, if a higher resolution of apr_time_now is needed, this should be suggested to the APR project. Additionally, if Windows NT and 2003 where chosen by purpose, those platforms are not supported anymore by Microsoft itself, so we shouldn't care much as well. All somewhat current versions of Windows seem to provide a high resolution with apr_time_now. I'm closing this for now. > 15-16 milliseconds granularity on Windows > -- > > Key: LOGCXX-361 > URL: https://issues.apache.org/jira/browse/LOGCXX-361 > Project: Log4cxx > Issue Type: Improvement > Components: Layout > Environment: Windows NT/2003 >Reporter: Sameer Gupta >Assignee: Curt Arnold > Original Estimate: 72h > Remaining Estimate: 72h > > I have noticed the message timestamps being logged are atleast 15-16 > milliseconds apart on windows NT/2003 systems even though the messages > actually requested to be logged were just couple of milliseconds apart. This > is due to the functions being used in the log4cxx code which are based on the > SYSTEMTIME structure. The accuracy of these functions is 15-16 milliseconds > at the most. I have tried to play around with the code and implemented > performance counters to produce sub 15-16 milliseconds accuracy between two > message timestamps. This will specially help the users who develop low > latency applications. > > I am wondering if I can contribute my work to the project. Please let me know > how I can join the project as a developer and what is the procedure to > contribute. Opologies, if this has already been implemented. > > Regards, > Sameer -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (LOGCXX-493) Documentation claiming `getTimeStamp` is in milliseconds but actually is in microseconds
[
https://issues.apache.org/jira/browse/LOGCXX-493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thorsten Schöning resolved LOGCXX-493.
--
Resolution: Fixed
Thanks for the report, I fixed this in master and latest_stable-branch to be
able to at least provide some fixed apidocs for the latest stable release
online.
https://logging.apache.org/log4cxx/latest_stable/apidocs/classlog4cxx_1_1spi_1_1_logging_event.html#a94cf977261a98da0cc53f2346f3a45d0
> Documentation claiming `getTimeStamp` is in milliseconds but actually is in
> microseconds
>
>
> Key: LOGCXX-493
> URL: https://issues.apache.org/jira/browse/LOGCXX-493
> Project: Log4cxx
> Issue Type: Bug
> Components: Documentation
>Affects Versions: 0.10.0
>Reporter: Vincent Thiery
>Assignee: Thorsten Schöning
>Priority: Minor
> Labels: easyfix
> Fix For: 0.11.0
>
>
> The documentation implies that `getTimeStamp` returns a timesamp in
> *milliseconds*, see:
> {code:cpp}
> /** Return the timeStamp of this event. */
> inline log4cxx_time_t getTimeStamp() const
> { return timeStamp; }
> {code}
> and the member
> {code:cpp}
> /** The number of milliseconds elapsed from 1/1/1970 until logging event
> was created. */
> log4cxx_time_t timeStamp;
> {code}
> The problem is that in the constructor of `LoggingEvent`, the timestamp is
> filled with `apr_time_now()` that returns a timestamp in *microseconds*, see:
> {code:cpp}
> LoggingEvent::LoggingEvent(
> const LogString& logger1, const LevelPtr& level1,
> const LogString& message1, const LocationInfo& locationInfo1) :
>logger(logger1),
>level(level1),
>ndc(0),
>mdcCopy(0),
>properties(0),
>ndcLookupRequired(true),
>mdcCopyLookupRequired(true),
>message(message1),
>timeStamp(apr_time_now()),
>locationInfo(locationInfo1),
>threadName(getCurrentThreadName()) {
> }
> {code}
> When encountered, the issue is not difficult to debug, but it would be nice
> to correct the documentation.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (LOGCXX-493) Documentation claiming `getTimeStamp` is in milliseconds but actually is in microseconds
[
https://issues.apache.org/jira/browse/LOGCXX-493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thorsten Schöning updated LOGCXX-493:
-
Fix Version/s: 0.11.0
> Documentation claiming `getTimeStamp` is in milliseconds but actually is in
> microseconds
>
>
> Key: LOGCXX-493
> URL: https://issues.apache.org/jira/browse/LOGCXX-493
> Project: Log4cxx
> Issue Type: Bug
> Components: Documentation
>Affects Versions: 0.10.0
>Reporter: Vincent Thiery
>Assignee: Thorsten Schöning
>Priority: Minor
> Labels: easyfix
> Fix For: 0.11.0
>
>
> The documentation implies that `getTimeStamp` returns a timesamp in
> *milliseconds*, see:
> {code:cpp}
> /** Return the timeStamp of this event. */
> inline log4cxx_time_t getTimeStamp() const
> { return timeStamp; }
> {code}
> and the member
> {code:cpp}
> /** The number of milliseconds elapsed from 1/1/1970 until logging event
> was created. */
> log4cxx_time_t timeStamp;
> {code}
> The problem is that in the constructor of `LoggingEvent`, the timestamp is
> filled with `apr_time_now()` that returns a timestamp in *microseconds*, see:
> {code:cpp}
> LoggingEvent::LoggingEvent(
> const LogString& logger1, const LevelPtr& level1,
> const LogString& message1, const LocationInfo& locationInfo1) :
>logger(logger1),
>level(level1),
>ndc(0),
>mdcCopy(0),
>properties(0),
>ndcLookupRequired(true),
>mdcCopyLookupRequired(true),
>message(message1),
>timeStamp(apr_time_now()),
>locationInfo(locationInfo1),
>threadName(getCurrentThreadName()) {
> }
> {code}
> When encountered, the issue is not difficult to debug, but it would be nice
> to correct the documentation.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (LOGCXX-493) Documentation claiming `getTimeStamp` is in milliseconds but actually is in microseconds
[
https://issues.apache.org/jira/browse/LOGCXX-493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thorsten Schöning reassigned LOGCXX-493:
Assignee: Thorsten Schöning
> Documentation claiming `getTimeStamp` is in milliseconds but actually is in
> microseconds
>
>
> Key: LOGCXX-493
> URL: https://issues.apache.org/jira/browse/LOGCXX-493
> Project: Log4cxx
> Issue Type: Bug
> Components: Documentation
>Affects Versions: 0.10.0
>Reporter: Vincent Thiery
>Assignee: Thorsten Schöning
>Priority: Minor
> Labels: easyfix
>
> The documentation implies that `getTimeStamp` returns a timesamp in
> *milliseconds*, see:
> {code:cpp}
> /** Return the timeStamp of this event. */
> inline log4cxx_time_t getTimeStamp() const
> { return timeStamp; }
> {code}
> and the member
> {code:cpp}
> /** The number of milliseconds elapsed from 1/1/1970 until logging event
> was created. */
> log4cxx_time_t timeStamp;
> {code}
> The problem is that in the constructor of `LoggingEvent`, the timestamp is
> filled with `apr_time_now()` that returns a timestamp in *microseconds*, see:
> {code:cpp}
> LoggingEvent::LoggingEvent(
> const LogString& logger1, const LevelPtr& level1,
> const LogString& message1, const LocationInfo& locationInfo1) :
>logger(logger1),
>level(level1),
>ndc(0),
>mdcCopy(0),
>properties(0),
>ndcLookupRequired(true),
>mdcCopyLookupRequired(true),
>message(message1),
>timeStamp(apr_time_now()),
>locationInfo(locationInfo1),
>threadName(getCurrentThreadName()) {
> }
> {code}
> When encountered, the issue is not difficult to debug, but it would be nice
> to correct the documentation.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (LOGCXX-493) Documentation claiming `getTimeStamp` is in milliseconds but actually is in microseconds
[
https://issues.apache.org/jira/browse/LOGCXX-493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Thiery updated LOGCXX-493:
--
Summary: Documentation claiming `getTimeStamp` is in milliseconds but
actually is in microseconds (was: Documentation claiming `getTimeStamp` is in
milliseconds but really is in microseconds)
> Documentation claiming `getTimeStamp` is in milliseconds but actually is in
> microseconds
>
>
> Key: LOGCXX-493
> URL: https://issues.apache.org/jira/browse/LOGCXX-493
> Project: Log4cxx
> Issue Type: Bug
> Components: Documentation
>Affects Versions: 0.10.0
>Reporter: Vincent Thiery
>Priority: Minor
> Labels: easyfix
>
> The documentation implies that `getTimeStamp` returns a timesamp in
> *milliseconds*, see:
> {code:cpp}
> /** Return the timeStamp of this event. */
> inline log4cxx_time_t getTimeStamp() const
> { return timeStamp; }
> {code}
> and the member
> {code:cpp}
> /** The number of milliseconds elapsed from 1/1/1970 until logging event
> was created. */
> log4cxx_time_t timeStamp;
> {code}
> The problem is that in the constructor of `LoggingEvent`, the timestamp is
> filled with `apr_time_now()` that returns a timestamp in *microseconds*, see:
> {code:cpp}
> LoggingEvent::LoggingEvent(
> const LogString& logger1, const LevelPtr& level1,
> const LogString& message1, const LocationInfo& locationInfo1) :
>logger(logger1),
>level(level1),
>ndc(0),
>mdcCopy(0),
>properties(0),
>ndcLookupRequired(true),
>mdcCopyLookupRequired(true),
>message(message1),
>timeStamp(apr_time_now()),
>locationInfo(locationInfo1),
>threadName(getCurrentThreadName()) {
> }
> {code}
> When encountered, the issue is not difficult to debug, but it would be nice
> to correct the documentation.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (LOGCXX-493) Documentation claiming `getTimeStamp` is in milliseconds but really is in microseconds
Vincent Thiery created LOGCXX-493:
-
Summary: Documentation claiming `getTimeStamp` is in milliseconds
but really is in microseconds
Key: LOGCXX-493
URL: https://issues.apache.org/jira/browse/LOGCXX-493
Project: Log4cxx
Issue Type: Bug
Components: Documentation
Affects Versions: 0.10.0
Reporter: Vincent Thiery
Priority: Minor
The documentation implies that `getTimeStamp` returns a timesamp in
*milliseconds*, see:
{code:cpp}
/** Return the timeStamp of this event. */
inline log4cxx_time_t getTimeStamp() const
{ return timeStamp; }
{code}
and the member
{code:cpp}
/** The number of milliseconds elapsed from 1/1/1970 until logging event
was created. */
log4cxx_time_t timeStamp;
{code}
The problem is that in the constructor of `LoggingEvent`, the timestamp is
filled with `apr_time_now()` that returns a timestamp in *microseconds*, see:
{code:cpp}
LoggingEvent::LoggingEvent(
const LogString& logger1, const LevelPtr& level1,
const LogString& message1, const LocationInfo& locationInfo1) :
logger(logger1),
level(level1),
ndc(0),
mdcCopy(0),
properties(0),
ndcLookupRequired(true),
mdcCopyLookupRequired(true),
message(message1),
timeStamp(apr_time_now()),
locationInfo(locationInfo1),
threadName(getCurrentThreadName()) {
}
{code}
When encountered, the issue is not difficult to debug, but it would be nice to
correct the documentation.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LOG4J2-2076) Split up log4j-nosql into one module per appender
[ https://issues.apache.org/jira/browse/LOG4J2-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205320#comment-16205320 ] Ralph Goers commented on LOG4J2-2076: - I wasn't thinking that nosql would generate a jar. I would have no problem with those classes being under appender.nosql in core. I was just thinking I wouldn't want to have all 3 directories at the root level. > Split up log4j-nosql into one module per appender > - > > Key: LOG4J2-2076 > URL: https://issues.apache.org/jira/browse/LOG4J2-2076 > Project: Log4j 2 > Issue Type: Improvement > Components: Appenders >Affects Versions: 2.9.1 >Reporter: Mikael Ståldal > > The log4j-nosql module contains an arbitrary collection of appenders for > MongoDB, CouchDB and Cassandra. It should be split up into one module for > each appender. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2076) Split up log4j-nosql into one module per appender
[ https://issues.apache.org/jira/browse/LOG4J2-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205309#comment-16205309 ] Matt Sicker commented on LOG4J2-2076: - It could be. All the classes directly in this package: https://github.com/apache/logging-log4j2/tree/master/log4j-nosql/src/main/java/org/apache/logging/log4j/nosql/appender could be either moved to log4j-core, or they could be their own module that essentially provides some abstract base classes common to other NoSQL appenders. > Split up log4j-nosql into one module per appender > - > > Key: LOG4J2-2076 > URL: https://issues.apache.org/jira/browse/LOG4J2-2076 > Project: Log4j 2 > Issue Type: Improvement > Components: Appenders >Affects Versions: 2.9.1 >Reporter: Mikael Ståldal > > The log4j-nosql module contains an arbitrary collection of appenders for > MongoDB, CouchDB and Cassandra. It should be split up into one module for > each appender. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2076) Split up log4j-nosql into one module per appender
[ https://issues.apache.org/jira/browse/LOG4J2-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205301#comment-16205301 ] Ralph Goers commented on LOG4J2-2076: - Does it make sense to make nosql a multi-module parent for these 3 projects? > Split up log4j-nosql into one module per appender > - > > Key: LOG4J2-2076 > URL: https://issues.apache.org/jira/browse/LOG4J2-2076 > Project: Log4j 2 > Issue Type: Improvement > Components: Appenders >Affects Versions: 2.9.1 >Reporter: Mikael Ståldal > > The log4j-nosql module contains an arbitrary collection of appenders for > MongoDB, CouchDB and Cassandra. It should be split up into one module for > each appender. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2076) Split up log4j-nosql into one module per appender
[ https://issues.apache.org/jira/browse/LOG4J2-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205300#comment-16205300 ] Matt Sicker commented on LOG4J2-2076: - You may want to move some of the common code back in to log4j-core while you're at it. I did that with ColumnMapping already. > Split up log4j-nosql into one module per appender > - > > Key: LOG4J2-2076 > URL: https://issues.apache.org/jira/browse/LOG4J2-2076 > Project: Log4j 2 > Issue Type: Improvement > Components: Appenders >Affects Versions: 2.9.1 >Reporter: Mikael Ståldal > > The log4j-nosql module contains an arbitrary collection of appenders for > MongoDB, CouchDB and Cassandra. It should be split up into one module for > each appender. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (LOG4J2-2076) Split up log4j-nosql into one module per appender
Mikael Ståldal created LOG4J2-2076: -- Summary: Split up log4j-nosql into one module per appender Key: LOG4J2-2076 URL: https://issues.apache.org/jira/browse/LOG4J2-2076 Project: Log4j 2 Issue Type: Improvement Components: Appenders Affects Versions: 2.9.1 Reporter: Mikael Ståldal The log4j-nosql module contains an arbitrary collection of appenders for MongoDB, CouchDB and Cassandra. It should be split up into one module for each appender. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (LOG4J2-2075) Add module information to extended stack trace.
Ralph Goers created LOG4J2-2075: --- Summary: Add module information to extended stack trace. Key: LOG4J2-2075 URL: https://issues.apache.org/jira/browse/LOG4J2-2075 Project: Log4j 2 Issue Type: New Feature Affects Versions: 2.9.1 Reporter: Ralph Goers Java 9 has enhanced the StackTraceElement to include the module name and module version (which is odd since I didn't think modules had versions). The extended stack traces should include these in addition to the jar name and version. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2056) Modularize Log4j as automatic modules
[ https://issues.apache.org/jira/browse/LOG4J2-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205120#comment-16205120 ] ASF subversion and git services commented on LOG4J2-2056: - Commit 5c6d9bbfebe1d5a787b44a4079f83c5906b341c3 in logging-log4j2's branch refs/heads/master from rpopma [ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=5c6d9bb ] LOG4J2-2056 fixed typos > Modularize Log4j as automatic modules > - > > Key: LOG4J2-2056 > URL: https://issues.apache.org/jira/browse/LOG4J2-2056 > Project: Log4j 2 > Issue Type: New Feature >Affects Versions: 2.9.1 >Reporter: Ralph Goers >Assignee: Ralph Goers > Fix For: 2.10.0 > > > To fully support Java 9 all Log4j jars must (at least) be packaged as > automatic modules. We should, as much as possible, follow the recommendations > at http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html. Given > that the module names would be: > ||Artifact ID ||Module name|| > |log4j-api|org.apache.logging.log4j| > |log4j-core|org.apache.logging.log4j.core| > |log4j-1.2-api|org.apache.log4j| > |log4j-appserver|org.apache.logging.log4j.appserver| > |log4j-flume-ng|org.apache.logging.log4j.flume| > |log4j-iostreams|org.apache.logging.log4j.iostreams| > |log4j-jcl|org.apache.logging.log4j.jcl| > |log4j-jmx-gui|org.apache.logging.log4j.jmx.gui| > |log4j-jul|org.apache.logging.log4j.jul| > |log4j-nosql|org.apache.logging.log4j.nosql| > |log4j-osgi|org.apache.logging.log4j.osgi| > |log4j-sl4j-impl|org.apache.logging.log4j.slf4j.impl*| > |log4j-to-slf4j|org.apache.logging.log4j.slf4j| > |log4j-taglib|org.apache.logging.log4j.taglib| > |log4j-web|org.apache.logging.log4j.web| > # log4j-liquibase uses a package name outside the org.apache.logging.log4j > namespace so is not modularized. > # log4j-slf4j-impl cannot currently be modularized until the binding is > modified. It cannot have classes in the org.slf4j namespace. > # log4j-slf4j-impl and log4j-to-slf4j both use the same package name - > org.apache.logging.log4j.slf4j. This will remain the same as it will prevent > them both from being loaded at the same time. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2060) AbstactDatabase appender issue with AsyncLogger
[
https://issues.apache.org/jira/browse/LOG4J2-2060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205113#comment-16205113
]
Remko Popma commented on LOG4J2-2060:
-
I've committed a fix to master. It would be great if you could provide a unit
test if you have a chance.
> AbstactDatabase appender issue with AsyncLogger
> ---
>
> Key: LOG4J2-2060
> URL: https://issues.apache.org/jira/browse/LOG4J2-2060
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.8.1, 2.8.2
>Reporter: Tolga Kavukcu
>Assignee: Remko Popma
> Fix For: 2.10.0
>
>
> Log4j2 AsycLogger Implementation with a database appender has an issue.
> As i investigated the async logger mechanism works like that.
> Messages are put into DistruptorRingBuffer
> Than
> *RingBufferLogEventHandler*'s *onEvent* mehtod is called and message is
> passed to appender asyncronously.
> In *AbstractDatabaseAppender* case
> The messages also put into an *ArrayList* to make batches for bulk insert to
> table.
> {code:java}
> @Override
> public final void append(final LogEvent event) {
> this.readLock.lock();
> try {
> this.getManager().write(event);
> } catch (final LoggingException e) {
> LOGGER.error("Unable to write to database [{}] for appender [{}].",
> this.getManager().getName(),
> this.getName(), e);
> throw e;
> } catch (final Exception e) {
> LOGGER.error("Unable to write to database [{}] for appender [{}].",
> this.getManager().getName(),
> this.getName(), e);
> throw new AppenderLoggingException("Unable to write to database in
> appender: " + e.getMessage(), e);
> } finally {
> this.readLock.unlock();
> }
> }
> {code}
> Than *Abstract Database Manager* puts *LogEvent* into *ArrayList*
> {code:java}
> public final synchronized void write(final LogEvent event) {
> if (this.bufferSize > 0) {
> this.buffer.add(event);
> if (this.buffer.size() >= this.bufferSize || event.isEndOfBatch()) {
> this.flush();
> }
> } else {
> this.connectAndStart();
> try {
> this.writeInternal(event);
> } finally {
> this.commitAndClose();
> }
> }
> }
> {code}
> After that correspoding *LogEvent* object can be re-used in the
> *DistruptorRingBuffer* mechanism.
> When a delay happens in the database the *LogEvent* objects are overriden
> with same referance which causes inconsitency while preparing batches.
> I believe this points to a bug or design problem.
> I would like to contribute solution if anyone can guide where to start what
> might be the possible design.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LOG4J2-2060) AbstactDatabase appender issue with AsyncLogger
[
https://issues.apache.org/jira/browse/LOG4J2-2060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205112#comment-16205112
]
ASF subversion and git services commented on LOG4J2-2060:
-
Commit 334667c7acc2955e157572bfa3b8d0272a8f1495 in logging-log4j2's branch
refs/heads/master from rpopma
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=334667c ]
LOG4J2-2060 AbstractDatabaseManager should make a copy of LogEvents before
holding references to them: AsyncLogger log events are mutable
> AbstactDatabase appender issue with AsyncLogger
> ---
>
> Key: LOG4J2-2060
> URL: https://issues.apache.org/jira/browse/LOG4J2-2060
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.8.1, 2.8.2
>Reporter: Tolga Kavukcu
>Assignee: Remko Popma
> Fix For: 2.10.0
>
>
> Log4j2 AsycLogger Implementation with a database appender has an issue.
> As i investigated the async logger mechanism works like that.
> Messages are put into DistruptorRingBuffer
> Than
> *RingBufferLogEventHandler*'s *onEvent* mehtod is called and message is
> passed to appender asyncronously.
> In *AbstractDatabaseAppender* case
> The messages also put into an *ArrayList* to make batches for bulk insert to
> table.
> {code:java}
> @Override
> public final void append(final LogEvent event) {
> this.readLock.lock();
> try {
> this.getManager().write(event);
> } catch (final LoggingException e) {
> LOGGER.error("Unable to write to database [{}] for appender [{}].",
> this.getManager().getName(),
> this.getName(), e);
> throw e;
> } catch (final Exception e) {
> LOGGER.error("Unable to write to database [{}] for appender [{}].",
> this.getManager().getName(),
> this.getName(), e);
> throw new AppenderLoggingException("Unable to write to database in
> appender: " + e.getMessage(), e);
> } finally {
> this.readLock.unlock();
> }
> }
> {code}
> Than *Abstract Database Manager* puts *LogEvent* into *ArrayList*
> {code:java}
> public final synchronized void write(final LogEvent event) {
> if (this.bufferSize > 0) {
> this.buffer.add(event);
> if (this.buffer.size() >= this.bufferSize || event.isEndOfBatch()) {
> this.flush();
> }
> } else {
> this.connectAndStart();
> try {
> this.writeInternal(event);
> } finally {
> this.commitAndClose();
> }
> }
> }
> {code}
> After that correspoding *LogEvent* object can be re-used in the
> *DistruptorRingBuffer* mechanism.
> When a delay happens in the database the *LogEvent* objects are overriden
> with same referance which causes inconsitency while preparing batches.
> I believe this points to a bug or design problem.
> I would like to contribute solution if anyone can guide where to start what
> might be the possible design.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LOG4J2-2062) Add possibility of sending the key of a message to Kafka using KafkaAppender
[ https://issues.apache.org/jira/browse/LOG4J2-2062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205078#comment-16205078 ] Jorge Sanchez commented on LOG4J2-2062: --- I have created a new PR for the key lookup capability at https://github.com/apache/logging-log4j2/pull/117 > Add possibility of sending the key of a message to Kafka using KafkaAppender > > > Key: LOG4J2-2062 > URL: https://issues.apache.org/jira/browse/LOG4J2-2062 > Project: Log4j 2 > Issue Type: Improvement > Components: Appenders >Affects Versions: 2.9.0, 2.9.1 >Reporter: Jorge Sanchez >Assignee: Mikael Ståldal >Priority: Minor > > When using the KafkaAppender the KafkaManager only sends the value of a > message to a Kafka topic. > It could be useful to be able to assign a value to the key of that message > via configuration instead of having it null. > Check > https://github.com/apache/logging-log4j2/blob/master/log4j-core/src/main/java/org/apache/logging/log4j/core/appender/mom/kafka/KafkaManager.java#L99 > Updated with link to the PR: https://github.com/apache/logging-log4j2/pull/112 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2067) Using PatternSelectors breaks header printing in PatternLayout
[
https://issues.apache.org/jira/browse/LOG4J2-2067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205055#comment-16205055
]
Paul Burrowes commented on LOG4J2-2067:
---
This tests the patch. I would create a PR but I'm a bit pressed for time this
month.
> Using PatternSelectors breaks header printing in PatternLayout
> --
>
> Key: LOG4J2-2067
> URL: https://issues.apache.org/jira/browse/LOG4J2-2067
> Project: Log4j 2
> Issue Type: Bug
> Components: Layouts, Pattern Converters
>Affects Versions: 2.8.2, 2.9.0
>Reporter: Paul Burrowes
>
> Using a config of
> {code}
>
>
>
>
>
>
> filePattern="foo.log.%i">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> the header is expected to be formatted according to the pattern configured
> but instead the output is
> {code}
> 2017-10-09 14:25:12.072+1300
> 2017-10-09 14:25:12.143+1300 using interpolation and a throwable
> java.lang.NullPointerException
> java.lang.NullPointerException: null
> at leliel.Main.main(Main.java:51) [Log4j2-testing/:?]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ~[?:1.7.0_79]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> ~[?:1.7.0_79]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[?:1.7.0_79]
> at java.lang.reflect.Method.invoke(Method.java:606) ~[?:1.7.0_79]
> at
> com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> [idea_rt.jar:?]
> 2017-10-09 14:25:12.151+1300 throwable only
> {code}
> The fix appears to simply be to not provide the PatternSelector to the header
> and footer Serializer builders.
> {code}
> diff --git
> a/log4j-core/src/main/java/org/apache/logging/log4j/core/layout/PatternLayout.java
>
> b/log4j-core/src/main/java/org/apache/logging/log4j/core/layout/PatternLayout.java
> index e4440eb9b..39042081f 100644
> ---
> a/log4j-core/src/main/java/org/apache/logging/log4j/core/layout/PatternLayout.java
> +++
> b/log4j-core/src/main/java/org/apache/logging/log4j/core/layout/PatternLayout.java
> @@ -108,7 +108,7 @@ public final class PatternLayout extends
> AbstractStringLayout {
> newSerializerBuilder()
> .setConfiguration(config)
> .setReplace(replace)
> -.setPatternSelector(patternSelector)
> +.setPatternSelector(null)
> .setAlwaysWriteExceptions(alwaysWriteExceptions)
> .setDisableAnsi(disableAnsi)
> .setNoConsoleNoAnsi(noConsoleNoAnsi)
> @@ -117,7 +117,7 @@ public final class PatternLayout extends
> AbstractStringLayout {
> newSerializerBuilder()
> .setConfiguration(config)
> .setReplace(replace)
> -.setPatternSelector(patternSelector)
> + .setPatternSelector(null)
> .setAlwaysWriteExceptions(alwaysWriteExceptions)
> .setDisableAnsi(disableAnsi)
> .setNoConsoleNoAnsi(noConsoleNoAnsi)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LOG4J2-2056) Modularize Log4j as automatic modules
[ https://issues.apache.org/jira/browse/LOG4J2-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205050#comment-16205050 ] ASF subversion and git services commented on LOG4J2-2056: - Commit 187e7139a79f4321a143cfb14e3e7652745cb4cb in logging-log4j2's branch refs/heads/master from [~ralph_go...@dslextreme.com] [ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=187e713 ] LOG4J2-2056 - Document modules > Modularize Log4j as automatic modules > - > > Key: LOG4J2-2056 > URL: https://issues.apache.org/jira/browse/LOG4J2-2056 > Project: Log4j 2 > Issue Type: New Feature >Affects Versions: 2.9.1 >Reporter: Ralph Goers >Assignee: Ralph Goers > Fix For: 2.10.0 > > > To fully support Java 9 all Log4j jars must (at least) be packaged as > automatic modules. We should, as much as possible, follow the recommendations > at http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html. Given > that the module names would be: > ||Artifact ID ||Module name|| > |log4j-api|org.apache.logging.log4j| > |log4j-core|org.apache.logging.log4j.core| > |log4j-1.2-api|org.apache.log4j| > |log4j-appserver|org.apache.logging.log4j.appserver| > |log4j-flume-ng|org.apache.logging.log4j.flume| > |log4j-iostreams|org.apache.logging.log4j.iostreams| > |log4j-jcl|org.apache.logging.log4j.jcl| > |log4j-jmx-gui|org.apache.logging.log4j.jmx.gui| > |log4j-jul|org.apache.logging.log4j.jul| > |log4j-nosql|org.apache.logging.log4j.nosql| > |log4j-osgi|org.apache.logging.log4j.osgi| > |log4j-sl4j-impl|org.apache.logging.log4j.slf4j.impl*| > |log4j-to-slf4j|org.apache.logging.log4j.slf4j| > |log4j-taglib|org.apache.logging.log4j.taglib| > |log4j-web|org.apache.logging.log4j.web| > # log4j-liquibase uses a package name outside the org.apache.logging.log4j > namespace so is not modularized. > # log4j-slf4j-impl cannot currently be modularized until the binding is > modified. It cannot have classes in the org.slf4j namespace. > # log4j-slf4j-impl and log4j-to-slf4j both use the same package name - > org.apache.logging.log4j.slf4j. This will remain the same as it will prevent > them both from being loaded at the same time. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (LOG4J2-2056) Modularize Log4j as automatic modules
[ https://issues.apache.org/jira/browse/LOG4J2-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralph Goers resolved LOG4J2-2056. - Resolution: Fixed Fix Version/s: 2.10.0 Fix has been committed. > Modularize Log4j as automatic modules > - > > Key: LOG4J2-2056 > URL: https://issues.apache.org/jira/browse/LOG4J2-2056 > Project: Log4j 2 > Issue Type: New Feature >Affects Versions: 2.9.1 >Reporter: Ralph Goers >Assignee: Ralph Goers > Fix For: 2.10.0 > > > To fully support Java 9 all Log4j jars must (at least) be packaged as > automatic modules. We should, as much as possible, follow the recommendations > at http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html. Given > that the module names would be: > ||Artifact ID ||Module name|| > |log4j-api|org.apache.logging.log4j| > |log4j-core|org.apache.logging.log4j.core| > |log4j-1.2-api|org.apache.log4j| > |log4j-appserver|org.apache.logging.log4j.appserver| > |log4j-flume-ng|org.apache.logging.log4j.flume| > |log4j-iostreams|org.apache.logging.log4j.iostreams| > |log4j-jcl|org.apache.logging.log4j.jcl| > |log4j-jmx-gui|org.apache.logging.log4j.jmx.gui| > |log4j-jul|org.apache.logging.log4j.jul| > |log4j-nosql|org.apache.logging.log4j.nosql| > |log4j-osgi|org.apache.logging.log4j.osgi| > |log4j-sl4j-impl|org.apache.logging.log4j.slf4j.impl*| > |log4j-to-slf4j|org.apache.logging.log4j.slf4j| > |log4j-taglib|org.apache.logging.log4j.taglib| > |log4j-web|org.apache.logging.log4j.web| > # log4j-liquibase uses a package name outside the org.apache.logging.log4j > namespace so is not modularized. > # log4j-slf4j-impl cannot currently be modularized until the binding is > modified. It cannot have classes in the org.slf4j namespace. > # log4j-slf4j-impl and log4j-to-slf4j both use the same package name - > org.apache.logging.log4j.slf4j. This will remain the same as it will prevent > them both from being loaded at the same time. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (LOG4J2-2056) Modularize Log4j as automatic modules
[ https://issues.apache.org/jira/browse/LOG4J2-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralph Goers updated LOG4J2-2056: Description: To fully support Java 9 all Log4j jars must (at least) be packaged as automatic modules. We should, as much as possible, follow the recommendations at http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html. Given that the module names would be: ||Artifact ID ||Module name|| |log4j-api|org.apache.logging.log4j| |log4j-core|org.apache.logging.log4j.core| |log4j-1.2-api|org.apache.log4j| |log4j-appserver|org.apache.logging.log4j.appserver| |log4j-flume-ng|org.apache.logging.log4j.flume| |log4j-iostreams|org.apache.logging.log4j.iostreams| |log4j-jcl|org.apache.logging.log4j.jcl| |log4j-jmx-gui|org.apache.logging.log4j.jmx.gui| |log4j-jul|org.apache.logging.log4j.jul| |log4j-nosql|org.apache.logging.log4j.nosql| |log4j-osgi|org.apache.logging.log4j.osgi| |log4j-sl4j-impl|org.apache.logging.log4j.slf4j.impl*| |log4j-to-slf4j|org.apache.logging.log4j.slf4j| |log4j-taglib|org.apache.logging.log4j.taglib| |log4j-web|org.apache.logging.log4j.web| # log4j-liquibase uses a package name outside the org.apache.logging.log4j namespace so is not modularized. # log4j-slf4j-impl cannot currently be modularized until the binding is modified. It cannot have classes in the org.slf4j namespace. # log4j-slf4j-impl and log4j-to-slf4j both use the same package name - org.apache.logging.log4j.slf4j. This will remain the same as it will prevent them both from being loaded at the same time. was: To fully support Java 9 all Log4j jars must (at least) be packaged as automatic modules. We should, as much as possible, follow the recommendations at http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html. Given that the module names would be: ||Artifact ID ||Module name|| |log4j-api|org.apache.logging.log4j| |log4j-core|org.apache.logging.log4j.core| |log4j-1.2-api|org.apache.log4j| |log4j-appserver|org.apache.logging.log4j.appserver| |log4j-flume-ng|org.apache.logging.log4j.flume| |log4j-iostreams|org.apache.logging.log4j.iostreams| |log4j-jcl|org.apache.logging.log4j.jcl| |log4j-jmx-gui|org.apache.logging.log4j.jmx.gui| |log4j-jul|org.apache.logging.log4j.jul| |log4j-nosql|org.apache.logging.log4j.nosql| |log4j-osgi|org.apache.logging.log4j.osgi| |log4j-sl4j-impl|org.apache.logging.log4j.slf4j.impl*| |log4j-to-slf4j|org.apache.logging.log4j.to.slf4j| |log4j-taglib|org.apache.logging.log4j.taglib| |log4j-web|org.apache.logging.log4j.web| # log4j-liquibase uses a package name outside the org.apache.logging.log4j namespace so is not modularized. # log4j-slf4j-impl cannot currently be modularized until the binding is modified. It cannot have classes in the org.slf4j namespace. # log4j-slf4j-impl and log4j-to-slf4j both use the same package name - org.apache.logging.log4j.slf4j. This will remain the same as it will prevent them both from being loaded at the same time. > Modularize Log4j as automatic modules > - > > Key: LOG4J2-2056 > URL: https://issues.apache.org/jira/browse/LOG4J2-2056 > Project: Log4j 2 > Issue Type: New Feature >Affects Versions: 2.9.1 >Reporter: Ralph Goers >Assignee: Ralph Goers > > To fully support Java 9 all Log4j jars must (at least) be packaged as > automatic modules. We should, as much as possible, follow the recommendations > at http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html. Given > that the module names would be: > ||Artifact ID ||Module name|| > |log4j-api|org.apache.logging.log4j| > |log4j-core|org.apache.logging.log4j.core| > |log4j-1.2-api|org.apache.log4j| > |log4j-appserver|org.apache.logging.log4j.appserver| > |log4j-flume-ng|org.apache.logging.log4j.flume| > |log4j-iostreams|org.apache.logging.log4j.iostreams| > |log4j-jcl|org.apache.logging.log4j.jcl| > |log4j-jmx-gui|org.apache.logging.log4j.jmx.gui| > |log4j-jul|org.apache.logging.log4j.jul| > |log4j-nosql|org.apache.logging.log4j.nosql| > |log4j-osgi|org.apache.logging.log4j.osgi| > |log4j-sl4j-impl|org.apache.logging.log4j.slf4j.impl*| > |log4j-to-slf4j|org.apache.logging.log4j.slf4j| > |log4j-taglib|org.apache.logging.log4j.taglib| > |log4j-web|org.apache.logging.log4j.web| > # log4j-liquibase uses a package name outside the org.apache.logging.log4j > namespace so is not modularized. > # log4j-slf4j-impl cannot currently be modularized until the binding is > modified. It cannot have classes in the org.slf4j namespace. > # log4j-slf4j-impl and log4j-to-slf4j both use the same package name - > org.apache.logging.log4j.slf4j. This will remain the same as it will prevent > them both from being loaded at the same time. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (LOG4J2-2056) Modularize Log4j as automatic modules
[ https://issues.apache.org/jira/browse/LOG4J2-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204848#comment-16204848 ] Ralph Goers edited comment on LOG4J2-2056 at 10/14/17 11:09 PM: Another thought. Log4j allows the log4j api and impl to be specified in the tomcat classloader for use by Tomcat. It also allows those two jars to be present in the classpath of the web app for its use. Currently, both sets may be present. I am afraid that this is going to fail should tomcat ever expose the jars in tomcat's lib directory on the module path of the web app. I guess we will have to wait and see what happens when tomcat adds support for modules. was (Author: ralph.go...@dslextreme.com): Another thought. Log4j allows the log4j api and impl to be specified in the tomcat classloader for use by Tomcat. It also allows those two jars to be present in the classpath of the web app for its use. Currently, both sets may be present. I am afraid that this is going to fail should tomcat ever expose the jars in tomcat's lib directory on the module path of the web app. > Modularize Log4j as automatic modules > - > > Key: LOG4J2-2056 > URL: https://issues.apache.org/jira/browse/LOG4J2-2056 > Project: Log4j 2 > Issue Type: New Feature >Affects Versions: 2.9.1 >Reporter: Ralph Goers >Assignee: Ralph Goers > > To fully support Java 9 all Log4j jars must (at least) be packaged as > automatic modules. We should, as much as possible, follow the recommendations > at http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html. Given > that the module names would be: > ||Artifact ID ||Module name|| > |log4j-api|org.apache.logging.log4j| > |log4j-core|org.apache.logging.log4j.core| > |log4j-1.2-api|org.apache.log4j| > |log4j-appserver|org.apache.logging.log4j.appserver| > |log4j-flume-ng|org.apache.logging.log4j.flume| > |log4j-iostreams|org.apache.logging.log4j.iostreams| > |log4j-jcl|org.apache.logging.log4j.jcl| > |log4j-jmx-gui|org.apache.logging.log4j.jmx.gui| > |log4j-jul|org.apache.logging.log4j.jul| > |log4j-nosql|org.apache.logging.log4j.nosql| > |log4j-osgi|org.apache.logging.log4j.osgi| > |log4j-sl4j-impl|org.apache.logging.log4j.slf4j.impl*| > |log4j-to-slf4j|org.apache.logging.log4j.to.slf4j| > |log4j-taglib|org.apache.logging.log4j.taglib| > |log4j-web|org.apache.logging.log4j.web| > # log4j-liquibase uses a package name outside the org.apache.logging.log4j > namespace so is not modularized. > # log4j-slf4j-impl cannot currently be modularized until the binding is > modified. It cannot have classes in the org.slf4j namespace. > # log4j-slf4j-impl and log4j-to-slf4j both use the same package name - > org.apache.logging.log4j.slf4j. This will remain the same as it will prevent > them both from being loaded at the same time. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-1431) Simplify log4j system property naming scheme
[ https://issues.apache.org/jira/browse/LOG4J2-1431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204740#comment-16204740 ] ASF subversion and git services commented on LOG4J2-1431: - Commit 11dd04acc15d1ba592f9693804d5e265963cda5e in logging-log4j2's branch refs/heads/master from [~jvz] [ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=11dd04a ] Add legacy properties unit test Related to LOG4J2-1431. > Simplify log4j system property naming scheme > > > Key: LOG4J2-1431 > URL: https://issues.apache.org/jira/browse/LOG4J2-1431 > Project: Log4j 2 > Issue Type: Improvement >Reporter: Matt Sicker >Assignee: Matt Sicker > Fix For: 2.10.0 > > > As I wonder how to prefix yet another configurable system property, I noticed > we have five families of configuration name prefixes: > log4j.* > log4j2.* > Log4j* > org.apache.logging.log4j.* > > What I'd like to do is strip out all those prefixes and allow any of them, > but change the documentation to use only a single consistent prefix. This > would also make it simpler when writing the properties into a > log4j2.component.properties file as you could omit all the prefixes as they > won't clash with other libraries. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (LOG4J2-1431) Simplify log4j system property naming scheme
[ https://issues.apache.org/jira/browse/LOG4J2-1431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker resolved LOG4J2-1431. - Resolution: Fixed Fix Version/s: 2.10.0 Merged to master. > Simplify log4j system property naming scheme > > > Key: LOG4J2-1431 > URL: https://issues.apache.org/jira/browse/LOG4J2-1431 > Project: Log4j 2 > Issue Type: Improvement >Reporter: Matt Sicker >Assignee: Matt Sicker > Fix For: 2.10.0 > > > As I wonder how to prefix yet another configurable system property, I noticed > we have five families of configuration name prefixes: > log4j.* > log4j2.* > Log4j* > org.apache.logging.log4j.* > > What I'd like to do is strip out all those prefixes and allow any of them, > but change the documentation to use only a single consistent prefix. This > would also make it simpler when writing the properties into a > log4j2.component.properties file as you could omit all the prefixes as they > won't clash with other libraries. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (LOG4J2-1809) Add global configuration environment SPI
[ https://issues.apache.org/jira/browse/LOG4J2-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker resolved LOG4J2-1809. - Resolution: Fixed Fix Version/s: 2.10.0 Merged to master. > Add global configuration environment SPI > > > Key: LOG4J2-1809 > URL: https://issues.apache.org/jira/browse/LOG4J2-1809 > Project: Log4j 2 > Issue Type: New Feature > Components: API >Reporter: Matt Sicker >Assignee: Matt Sicker > Fix For: 2.10.0 > > > Create a service provider interface for global configuration property > sources. Currently, we support two built in sources: properties loaded from a > classpath resource file named "log4j2.component.properties" and from system > properties. This feature will abstract those two sources into an SPI with > default implementations of those two sources as well as environment variables. > This SPI should be specified through the standard > [ServiceLoader|https://docs.oracle.com/javase/8/docs/api/java/util/ServiceLoader.html] > API so as to make this simpler to support for users in any environment. > Related to LOG4J2-1431. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-1431) Simplify log4j system property naming scheme
[ https://issues.apache.org/jira/browse/LOG4J2-1431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204743#comment-16204743 ] ASF subversion and git services commented on LOG4J2-1431: - Commit 06dcce455c0409f47e808fbf837a136f140e18de in logging-log4j2's branch refs/heads/master from [~jvz] [ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=06dcce4 ] Merge branch 'LOG4J2-1431' and fix version numbers # Conflicts: # log4j-api/src/main/java/org/apache/logging/log4j/util/PropertiesUtil.java # src/changes/changes.xml > Simplify log4j system property naming scheme > > > Key: LOG4J2-1431 > URL: https://issues.apache.org/jira/browse/LOG4J2-1431 > Project: Log4j 2 > Issue Type: Improvement >Reporter: Matt Sicker >Assignee: Matt Sicker > Fix For: 2.10.0 > > > As I wonder how to prefix yet another configurable system property, I noticed > we have five families of configuration name prefixes: > log4j.* > log4j2.* > Log4j* > org.apache.logging.log4j.* > > What I'd like to do is strip out all those prefixes and allow any of them, > but change the documentation to use only a single consistent prefix. This > would also make it simpler when writing the properties into a > log4j2.component.properties file as you could omit all the prefixes as they > won't clash with other libraries. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-1431) Simplify log4j system property naming scheme
[ https://issues.apache.org/jira/browse/LOG4J2-1431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204741#comment-16204741 ] ASF subversion and git services commented on LOG4J2-1431: - Commit 36f70030762b9b29d87b747f769ef6f90f76c83b in logging-log4j2's branch refs/heads/master from [~jvz] [ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=36f7003 ] Update manual for LOG4J2-1431 and LOG4J2-1809 > Simplify log4j system property naming scheme > > > Key: LOG4J2-1431 > URL: https://issues.apache.org/jira/browse/LOG4J2-1431 > Project: Log4j 2 > Issue Type: Improvement >Reporter: Matt Sicker >Assignee: Matt Sicker > Fix For: 2.10.0 > > > As I wonder how to prefix yet another configurable system property, I noticed > we have five families of configuration name prefixes: > log4j.* > log4j2.* > Log4j* > org.apache.logging.log4j.* > > What I'd like to do is strip out all those prefixes and allow any of them, > but change the documentation to use only a single consistent prefix. This > would also make it simpler when writing the properties into a > log4j2.component.properties file as you could omit all the prefixes as they > won't clash with other libraries. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2074) The console appender should say why it cannot load JAnsi
[ https://issues.apache.org/jira/browse/LOG4J2-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204197#comment-16204197 ] ASF subversion and git services commented on LOG4J2-2074: - Commit 1357d4cc958d4aaa251b5c3223e29713b20fcf63 in logging-log4j2's branch refs/heads/master from ggregory [ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=1357d4c ] [LOG4J2-2074] The console appender should say why it cannot load JAnsi. > The console appender should say why it cannot load JAnsi > > > Key: LOG4J2-2074 > URL: https://issues.apache.org/jira/browse/LOG4J2-2074 > Project: Log4j 2 > Issue Type: Bug > Components: Appenders, Core >Affects Versions: 2.9.1 >Reporter: Gary Gregory >Assignee: Gary Gregory > Fix For: 2.10.0 > > > The console appender should say why it cannot load JAnsi -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (LOG4J2-2074) The console appender should say why it cannot load JAnsi
[ https://issues.apache.org/jira/browse/LOG4J2-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed LOG4J2-2074. Resolution: Fixed Fix Version/s: 2.10.0 In git master. > The console appender should say why it cannot load JAnsi > > > Key: LOG4J2-2074 > URL: https://issues.apache.org/jira/browse/LOG4J2-2074 > Project: Log4j 2 > Issue Type: Bug > Components: Appenders, Core >Affects Versions: 2.9.1 >Reporter: Gary Gregory >Assignee: Gary Gregory > Fix For: 2.10.0 > > > The console appender should say why it cannot load JAnsi -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (LOG4J2-2074) The console appender should say why it cannot load JAnsi
Gary Gregory created LOG4J2-2074: Summary: The console appender should say why it cannot load JAnsi Key: LOG4J2-2074 URL: https://issues.apache.org/jira/browse/LOG4J2-2074 Project: Log4j 2 Issue Type: Bug Components: Appenders, Core Affects Versions: 2.9.1 Reporter: Gary Gregory Assignee: Gary Gregory The console appender should say why it cannot load JAnsi -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (LOG4J2-2073) Log4j-config.xsd should make AppenderRef optional for each Logger element
[ https://issues.apache.org/jira/browse/LOG4J2-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed LOG4J2-2073. Resolution: Fixed Fix Version/s: 2.10.0 In git master. > Log4j-config.xsd should make AppenderRef optional for each Logger element > - > > Key: LOG4J2-2073 > URL: https://issues.apache.org/jira/browse/LOG4J2-2073 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.9.0, 2.9.1 >Reporter: Gary Gregory >Assignee: Gary Gregory > Fix For: 2.10.0 > > > Log4j-config.xsd should make AppenderRef optional for each Logger element. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2073) Log4j-config.xsd should make AppenderRef optional for each Logger element
[ https://issues.apache.org/jira/browse/LOG4J2-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204187#comment-16204187 ] ASF subversion and git services commented on LOG4J2-2073: - Commit 417e3049e0466fa3558f04a6c7f4955014619d7d in logging-log4j2's branch refs/heads/master from [~garydgregory] [ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=417e304 ] [LOG4J2-2073] Log4j-config.xsd should make AppenderRef optional for each Logger element. > Log4j-config.xsd should make AppenderRef optional for each Logger element > - > > Key: LOG4J2-2073 > URL: https://issues.apache.org/jira/browse/LOG4J2-2073 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.9.0, 2.9.1 >Reporter: Gary Gregory >Assignee: Gary Gregory > Fix For: 2.10.0 > > > Log4j-config.xsd should make AppenderRef optional for each Logger element. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2062) Add possibility of sending the key of a message to Kafka using KafkaAppender
[ https://issues.apache.org/jira/browse/LOG4J2-2062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204073#comment-16204073 ] Mikael Ståldal commented on LOG4J2-2062: The first PR is now merged. > Add possibility of sending the key of a message to Kafka using KafkaAppender > > > Key: LOG4J2-2062 > URL: https://issues.apache.org/jira/browse/LOG4J2-2062 > Project: Log4j 2 > Issue Type: Improvement > Components: Appenders >Affects Versions: 2.9.0, 2.9.1 >Reporter: Jorge Sanchez >Assignee: Mikael Ståldal >Priority: Minor > > When using the KafkaAppender the KafkaManager only sends the value of a > message to a Kafka topic. > It could be useful to be able to assign a value to the key of that message > via configuration instead of having it null. > Check > https://github.com/apache/logging-log4j2/blob/master/log4j-core/src/main/java/org/apache/logging/log4j/core/appender/mom/kafka/KafkaManager.java#L99 > Updated with link to the PR: https://github.com/apache/logging-log4j2/pull/112 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2062) Add possibility of sending the key of a message to Kafka using KafkaAppender
[ https://issues.apache.org/jira/browse/LOG4J2-2062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204070#comment-16204070 ] ASF subversion and git services commented on LOG4J2-2062: - Commit f57b356ddded447f3e46dd1469ae6f6ac44d3497 in logging-log4j2's branch refs/heads/master from [~Flowcont] [ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=f57b356 ] LOG4J2-2062 Added property to KafkaAppender to send a Key to Kafka Set key as an attribute, updated documentation and set charset > Add possibility of sending the key of a message to Kafka using KafkaAppender > > > Key: LOG4J2-2062 > URL: https://issues.apache.org/jira/browse/LOG4J2-2062 > Project: Log4j 2 > Issue Type: Improvement > Components: Appenders >Affects Versions: 2.9.0, 2.9.1 >Reporter: Jorge Sanchez >Assignee: Mikael Ståldal >Priority: Minor > > When using the KafkaAppender the KafkaManager only sends the value of a > message to a Kafka topic. > It could be useful to be able to assign a value to the key of that message > via configuration instead of having it null. > Check > https://github.com/apache/logging-log4j2/blob/master/log4j-core/src/main/java/org/apache/logging/log4j/core/appender/mom/kafka/KafkaManager.java#L99 > Updated with link to the PR: https://github.com/apache/logging-log4j2/pull/112 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2062) Add possibility of sending the key of a message to Kafka using KafkaAppender
[ https://issues.apache.org/jira/browse/LOG4J2-2062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204062#comment-16204062 ] ASF GitHub Bot commented on LOG4J2-2062: Github user mikaelstaldal commented on the issue: https://github.com/apache/logging-log4j2/pull/112 :+1: > Add possibility of sending the key of a message to Kafka using KafkaAppender > > > Key: LOG4J2-2062 > URL: https://issues.apache.org/jira/browse/LOG4J2-2062 > Project: Log4j 2 > Issue Type: Improvement > Components: Appenders >Affects Versions: 2.9.0, 2.9.1 >Reporter: Jorge Sanchez >Assignee: Mikael Ståldal >Priority: Minor > > When using the KafkaAppender the KafkaManager only sends the value of a > message to a Kafka topic. > It could be useful to be able to assign a value to the key of that message > via configuration instead of having it null. > Check > https://github.com/apache/logging-log4j2/blob/master/log4j-core/src/main/java/org/apache/logging/log4j/core/appender/mom/kafka/KafkaManager.java#L99 > Updated with link to the PR: https://github.com/apache/logging-log4j2/pull/112 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-1982) Log4j-config.xsd only allows one AppenderRef element for each Logger element
[
https://issues.apache.org/jira/browse/LOG4J2-1982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202777#comment-16202777
]
Gary Gregory commented on LOG4J2-1982:
--
Right! Fixing with https://issues.apache.org/jira/browse/LOG4J2-2073
> Log4j-config.xsd only allows one AppenderRef element for each Logger element
>
>
> Key: LOG4J2-1982
> URL: https://issues.apache.org/jira/browse/LOG4J2-1982
> Project: Log4j 2
> Issue Type: Bug
> Components: Configurators
>Affects Versions: 2.8.2
> Environment: Alle environments
>Reporter: Christoph Lembeck
> Fix For: 2.9.0
>
>
> The xsd schema definition for the log4j configuration allow only one
> AppenderRef per Logger. The definition of the Logger element is as follows
> {code:xml}
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> Comparing this to the Definition of the root Logger we see a sequence of
> multiple Appender
> Ref elements to be allowed.
> {code:xml}
>
>
> minOccurs="1" maxOccurs="unbounded"/>
>
>
>
> {code}
> With this configuration it is not possible to define a specific Logger, that
> shows infos and errors to the console and writes only the errors in a log
> file, since there can only be one appender defined for that logger.
> Please modify the xsd file to allow mutliple AppenderRef elements per Logger.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (LOG4J2-2073) Log4j-config.xsd should make AppenderRef optional for each Logger element
Gary Gregory created LOG4J2-2073: Summary: Log4j-config.xsd should make AppenderRef optional for each Logger element Key: LOG4J2-2073 URL: https://issues.apache.org/jira/browse/LOG4J2-2073 Project: Log4j 2 Issue Type: Bug Components: Core Affects Versions: 2.9.1, 2.9.0 Reporter: Gary Gregory Assignee: Gary Gregory Log4j-config.xsd should make AppenderRef optional for each Logger element. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (LOG4J2-2056) Modularize Log4j as automatic modules
[
https://issues.apache.org/jira/browse/LOG4J2-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202771#comment-16202771
]
Ralph Goers edited comment on LOG4J2-2056 at 10/12/17 11:07 PM:
What you described is pretty much how Log4j already works. The Log4j API
already binds to its implementation via the ServiceLoader. This is a bit of a
pain in OSGi but we got it to work. Because the Log4j API and implementation
are currently automatic modules we don't really care what the module names of
the implementations are.
Starting with release 1.8, SLF4J also uses the ServiceLoader. It's
module-info.java file contains
{code}
module org.slf4j {
exports org.slf4j;
exports org.slf4j.spi;
exports org.slf4j.event;
exports org.slf4j.helpers;
uses org.slf4j.spi.SLF4JServiceProvider;
}
{code}
It seems to me that nothing in there requires a specific module name for the
implementation so I am not sure that we would either.
FWIW, ServiceLoader doesn't preclude having multiple implementations.
was (Author: ralph.go...@dslextreme.com):
What you described is pretty much how Log4j already works. The Log4j API
already binds to its implementation via the ServiceLoader. This is a bit of a
pain in OSGi but we got it to work. Because the Log4j API and implementation
are currently automatic modules we don't really care what the module names of
the implementations are.
Starting with release 1.8, SLF4J also uses the ServiceLoader. It's
module-info.java file contains
{code}
module org.slf4j {
exports org.slf4j;
exports org.slf4j.spi;
exports org.slf4j.event;
exports org.slf4j.helpers;
uses org.slf4j.spi.SLF4JServiceProvider;
}
{code}
It seems to me that nothing in there requires a specific module name for the
implementation so I am not sure that we do either.
FWIW, ServiceLoader doesn't preclude having multiple implementations.
> Modularize Log4j as automatic modules
> -
>
> Key: LOG4J2-2056
> URL: https://issues.apache.org/jira/browse/LOG4J2-2056
> Project: Log4j 2
> Issue Type: New Feature
>Affects Versions: 2.9.1
>Reporter: Ralph Goers
>Assignee: Ralph Goers
>
> To fully support Java 9 all Log4j jars must (at least) be packaged as
> automatic modules. We should, as much as possible, follow the recommendations
> at http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html. Given
> that the module names would be:
> ||Artifact ID ||Module name||
> |log4j-api|org.apache.logging.log4j|
> |log4j-core|org.apache.logging.log4j.core|
> |log4j-1.2-api|org.apache.log4j|
> |log4j-appserver|org.apache.logging.log4j.appserver|
> |log4j-flume-ng|org.apache.logging.log4j.flume|
> |log4j-iostreams|org.apache.logging.log4j.iostreams|
> |log4j-jcl|org.apache.logging.log4j.jcl|
> |log4j-jmx-gui|org.apache.logging.log4j.jmx.gui|
> |log4j-jul|org.apache.logging.log4j.jul|
> |log4j-nosql|org.apache.logging.log4j.nosql|
> |log4j-osgi|org.apache.logging.log4j.osgi|
> |log4j-sl4j-impl|org.apache.logging.log4j.slf4j.impl*|
> |log4j-to-slf4j|org.apache.logging.log4j.to.slf4j|
> |log4j-taglib|org.apache.logging.log4j.taglib|
> |log4j-web|org.apache.logging.log4j.web|
> # log4j-liquibase uses a package name outside the org.apache.logging.log4j
> namespace so is not modularized.
> # log4j-slf4j-impl cannot currently be modularized until the binding is
> modified. It cannot have classes in the org.slf4j namespace.
> # log4j-slf4j-impl and log4j-to-slf4j both use the same package name -
> org.apache.logging.log4j.slf4j. This will remain the same as it will prevent
> them both from being loaded at the same time.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LOG4J2-2056) Modularize Log4j as automatic modules
[
https://issues.apache.org/jira/browse/LOG4J2-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202771#comment-16202771
]
Ralph Goers commented on LOG4J2-2056:
-
What you described is pretty much how Log4j already works. The Log4j API
already binds to its implementation via the ServiceLoader. This is a bit of a
pain in OSGi but we got it to work. Because the Log4j API and implementation
are currently automatic modules we don't really care what the module names of
the implementations are.
Starting with release 1.8, SLF4J also uses the ServiceLoader. It's
module-info.java file contains
{code}
module org.slf4j {
exports org.slf4j;
exports org.slf4j.spi;
exports org.slf4j.event;
exports org.slf4j.helpers;
uses org.slf4j.spi.SLF4JServiceProvider;
}
{code}
It seems to me that nothing in there requires a specific module name for the
implementation so I am not sure that we do either.
FWIW, ServiceLoader doesn't preclude having multiple implementations.
> Modularize Log4j as automatic modules
> -
>
> Key: LOG4J2-2056
> URL: https://issues.apache.org/jira/browse/LOG4J2-2056
> Project: Log4j 2
> Issue Type: New Feature
>Affects Versions: 2.9.1
>Reporter: Ralph Goers
>Assignee: Ralph Goers
>
> To fully support Java 9 all Log4j jars must (at least) be packaged as
> automatic modules. We should, as much as possible, follow the recommendations
> at http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html. Given
> that the module names would be:
> ||Artifact ID ||Module name||
> |log4j-api|org.apache.logging.log4j|
> |log4j-core|org.apache.logging.log4j.core|
> |log4j-1.2-api|org.apache.log4j|
> |log4j-appserver|org.apache.logging.log4j.appserver|
> |log4j-flume-ng|org.apache.logging.log4j.flume|
> |log4j-iostreams|org.apache.logging.log4j.iostreams|
> |log4j-jcl|org.apache.logging.log4j.jcl|
> |log4j-jmx-gui|org.apache.logging.log4j.jmx.gui|
> |log4j-jul|org.apache.logging.log4j.jul|
> |log4j-nosql|org.apache.logging.log4j.nosql|
> |log4j-osgi|org.apache.logging.log4j.osgi|
> |log4j-sl4j-impl|org.apache.logging.log4j.slf4j.impl*|
> |log4j-to-slf4j|org.apache.logging.log4j.to.slf4j|
> |log4j-taglib|org.apache.logging.log4j.taglib|
> |log4j-web|org.apache.logging.log4j.web|
> # log4j-liquibase uses a package name outside the org.apache.logging.log4j
> namespace so is not modularized.
> # log4j-slf4j-impl cannot currently be modularized until the binding is
> modified. It cannot have classes in the org.slf4j namespace.
> # log4j-slf4j-impl and log4j-to-slf4j both use the same package name -
> org.apache.logging.log4j.slf4j. This will remain the same as it will prevent
> them both from being loaded at the same time.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (LOG4J2-1216) Nested pattern layout options broken
[
https://issues.apache.org/jira/browse/LOG4J2-1216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory resolved LOG4J2-1216.
--
Resolution: Fixed
PR 116 applied. Please verify and close. Note that the unit test
{{org.apache.logging.log4j.core.pattern.PatternParserTest}} hangs without the
main code change, which is good.
> Nested pattern layout options broken
>
>
> Key: LOG4J2-1216
> URL: https://issues.apache.org/jira/browse/LOG4J2-1216
> Project: Log4j 2
> Issue Type: Bug
> Components: Pattern Converters
>Affects Versions: 2.4.1, 2.9.1
>Reporter: Thies Wellpott
> Labels: easyfix
> Fix For: 2.9.2
>
>
> Parsing the "deeply" nested PatternLayout
> {code}
> %maxLen{[XXX, ${hostName}, ${web:contextPath}] %p: %c{1} - %m%notEmpty{
> =>%ex{short}}}{160}
> {code}
> (with %maxLen being a custom Converter)
> results in wrong parsing.
> Patternparser.extractOptions() gets the nesting wrong.
> Solution:
> {code}
> private static int extractOptions(final String pattern, final int start,
> final List options) {
> int i = start;
> while (i < pattern.length() && pattern.charAt(i) == '{') {
> i++; // skip opening "{"
> final int begin = i; // position of first real char
> int depth = 1;// already inside one level
> while (depth > 0 && i < pattern.length()) {
> char c = pattern.charAt(i);
> if (c == '{') {
> depth++;
> } else if (c == '}') {
> depth--;
> // TODO(?) maybe escaping of { and } with \ or %
> }
> i++;
> } // while
> if (depth > 0) { // option not closed, continue with pattern
> on opening "{"
> return begin-1;
> }
> options.add(pattern.substring(begin, i-1));
> } // while
> return i;
> }
> {code}
> This should also be faster than the current implementation because the
> pattern ist only walked once, not multiple times with indexOf().
> (LOG4J2-107 is a similar but old bug)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LOG4J2-1216) Nested pattern layout options broken
[
https://issues.apache.org/jira/browse/LOG4J2-1216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202675#comment-16202675
]
ASF subversion and git services commented on LOG4J2-1216:
-
Commit 52461585ed34153dc1470acbf2d43aac9bc81944 in logging-log4j2's branch
refs/heads/master from GFriedrich
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=5246158 ]
[LOG4J2-1216] Nested pattern layout options broken. Apply slightly
tweaked patch for formatting. Fix hang and more tests. Closes #116.
> Nested pattern layout options broken
>
>
> Key: LOG4J2-1216
> URL: https://issues.apache.org/jira/browse/LOG4J2-1216
> Project: Log4j 2
> Issue Type: Bug
> Components: Pattern Converters
>Affects Versions: 2.4.1, 2.9.1
>Reporter: Thies Wellpott
> Labels: easyfix
> Fix For: 2.9.2
>
>
> Parsing the "deeply" nested PatternLayout
> {code}
> %maxLen{[XXX, ${hostName}, ${web:contextPath}] %p: %c{1} - %m%notEmpty{
> =>%ex{short}}}{160}
> {code}
> (with %maxLen being a custom Converter)
> results in wrong parsing.
> Patternparser.extractOptions() gets the nesting wrong.
> Solution:
> {code}
> private static int extractOptions(final String pattern, final int start,
> final List options) {
> int i = start;
> while (i < pattern.length() && pattern.charAt(i) == '{') {
> i++; // skip opening "{"
> final int begin = i; // position of first real char
> int depth = 1;// already inside one level
> while (depth > 0 && i < pattern.length()) {
> char c = pattern.charAt(i);
> if (c == '{') {
> depth++;
> } else if (c == '}') {
> depth--;
> // TODO(?) maybe escaping of { and } with \ or %
> }
> i++;
> } // while
> if (depth > 0) { // option not closed, continue with pattern
> on opening "{"
> return begin-1;
> }
> options.add(pattern.substring(begin, i-1));
> } // while
> return i;
> }
> {code}
> This should also be faster than the current implementation because the
> pattern ist only walked once, not multiple times with indexOf().
> (LOG4J2-107 is a similar but old bug)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LOG4J2-2056) Modularize Log4j as automatic modules
[ https://issues.apache.org/jira/browse/LOG4J2-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202658#comment-16202658 ] Neil Bartlett commented on LOG4J2-2056: --- Whatever name you choose, that is the name that modules must declare their requirement on. If a module depends on `org.apache.logging.log4j.slf4j` then it will be bound to that implementation and cannot use a substitute implementation such as Logback. JPMS only provides one mechanism for implementation substitution, and that is Services. To do this "properly" you would refactor the APIs so that they are pure interfaces with the implementation provided as a service. Then a consumer module need only depend on the pure API at build time, so long as an appropriate implementation is provided at assembly time. It seems unlikely this scenario can be achieved without breaking backwards compatibility. So it seems you have two choices. (a) Give each module a unique name, and live with coupling consumers to a specific implementation, or (b) Give all modules providing the same API the same module name, and live with the idea that artifact identity and module identity are decoupled. > Modularize Log4j as automatic modules > - > > Key: LOG4J2-2056 > URL: https://issues.apache.org/jira/browse/LOG4J2-2056 > Project: Log4j 2 > Issue Type: New Feature >Affects Versions: 2.9.1 >Reporter: Ralph Goers >Assignee: Ralph Goers > > To fully support Java 9 all Log4j jars must (at least) be packaged as > automatic modules. We should, as much as possible, follow the recommendations > at http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html. Given > that the module names would be: > ||Artifact ID ||Module name|| > |log4j-api|org.apache.logging.log4j| > |log4j-core|org.apache.logging.log4j.core| > |log4j-1.2-api|org.apache.log4j| > |log4j-appserver|org.apache.logging.log4j.appserver| > |log4j-flume-ng|org.apache.logging.log4j.flume| > |log4j-iostreams|org.apache.logging.log4j.iostreams| > |log4j-jcl|org.apache.logging.log4j.jcl| > |log4j-jmx-gui|org.apache.logging.log4j.jmx.gui| > |log4j-jul|org.apache.logging.log4j.jul| > |log4j-nosql|org.apache.logging.log4j.nosql| > |log4j-osgi|org.apache.logging.log4j.osgi| > |log4j-sl4j-impl|org.apache.logging.log4j.slf4j.impl*| > |log4j-to-slf4j|org.apache.logging.log4j.to.slf4j| > |log4j-taglib|org.apache.logging.log4j.taglib| > |log4j-web|org.apache.logging.log4j.web| > # log4j-liquibase uses a package name outside the org.apache.logging.log4j > namespace so is not modularized. > # log4j-slf4j-impl cannot currently be modularized until the binding is > modified. It cannot have classes in the org.slf4j namespace. > # log4j-slf4j-impl and log4j-to-slf4j both use the same package name - > org.apache.logging.log4j.slf4j. This will remain the same as it will prevent > them both from being loaded at the same time. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (LOG4J2-2056) Modularize Log4j as automatic modules
[ https://issues.apache.org/jira/browse/LOG4J2-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202635#comment-16202635 ] Ralph Goers edited comment on LOG4J2-2056 at 10/12/17 9:19 PM: --- [~njbartlett] Thanks for jumping in. The options are listed in the link Stephen created - https://github.com/jodastephen/jpms-module-names/wiki/Logging-APIs. Basically, it is a choice on whether to have multiple modules that implement the same thing all use the same module name or whether they should all be unique. SLF4J and the Log4j 2 API can each be bound to one of many logging implementations. So should Logback use org.slf4j.impl as its module name or Logback's package - ch.qos.logback. Likewise, Log4j's implementation could either be org.apache.logging.log4j.impl (a generic name) or org.apache.logging.log4j.core (the actual package name of the implementation). In the case of SLF4J, Log4j provides a "binding" that causes SLF4J to use Log4j. We would either also use org.slf4j.impl for that or we would use org.apache.logging.log4j.slf4j. Note that in the case of Log4j we could theoretically support multiple Log4j implementations although we currently only bind to one. Using a common module name would restrict that to only allow one. No one has ever asked to support multiple implementations so I don't really think that would be a problem. Right now these are all automatic modules - we can't turn them into "real" modules until all the dependencies have declared names - but we need to have the names be right on the first try. Unfortunately, JPMS doesn't provide any guidance on any of this. It is only with the help of folks like you and Stephen that Java frameworks are making any progress at all. was (Author: ralph.go...@dslextreme.com): [~njbartlett] Thanks for jumping in. The options are listed in the link Stephen created - https://github.com/jodastephen/jpms-module-names/wiki/Logging-APIs. Basically, it is a choice on whether to have multiple modules that implement the same thing all use the same module name or whether they should all be unique. SLF4J and the Log4j 2 API can each be bound to one of many logging implementations. So should Logback use org.slf4j.impl as its module name or Logback's package - ch.qos.logback. Likewise, Log4j's implementation could either be org.apache.logging.log4j.impl (a generic name) or org.apache.logging.log4j.core (the actual package name of the implementation). In the case of SLF4J, Log4j provides a "binding" that causes SLF4J to use Log4j. We would either also use org.slf4j.impl for that or we would use org.apache.logging.log4j.slf4j. Right now these are all automatic modules - we can't turn them into "real" modules until all the dependencies have declared names - but we need to have the names be right on the first try. Unfortunately, JPMS doesn't provide any guidance on any of this. It is only with the help of folks like you and Stephen that Java frameworks are making any progress at all. > Modularize Log4j as automatic modules > - > > Key: LOG4J2-2056 > URL: https://issues.apache.org/jira/browse/LOG4J2-2056 > Project: Log4j 2 > Issue Type: New Feature >Affects Versions: 2.9.1 >Reporter: Ralph Goers >Assignee: Ralph Goers > > To fully support Java 9 all Log4j jars must (at least) be packaged as > automatic modules. We should, as much as possible, follow the recommendations > at http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html. Given > that the module names would be: > ||Artifact ID ||Module name|| > |log4j-api|org.apache.logging.log4j| > |log4j-core|org.apache.logging.log4j.core| > |log4j-1.2-api|org.apache.log4j| > |log4j-appserver|org.apache.logging.log4j.appserver| > |log4j-flume-ng|org.apache.logging.log4j.flume| > |log4j-iostreams|org.apache.logging.log4j.iostreams| > |log4j-jcl|org.apache.logging.log4j.jcl| > |log4j-jmx-gui|org.apache.logging.log4j.jmx.gui| > |log4j-jul|org.apache.logging.log4j.jul| > |log4j-nosql|org.apache.logging.log4j.nosql| > |log4j-osgi|org.apache.logging.log4j.osgi| > |log4j-sl4j-impl|org.apache.logging.log4j.slf4j.impl*| > |log4j-to-slf4j|org.apache.logging.log4j.to.slf4j| > |log4j-taglib|org.apache.logging.log4j.taglib| > |log4j-web|org.apache.logging.log4j.web| > # log4j-liquibase uses a package name outside the org.apache.logging.log4j > namespace so is not modularized. > # log4j-slf4j-impl cannot currently be modularized until the binding is > modified. It cannot have classes in the org.slf4j namespace. > # log4j-slf4j-impl and log4j-to-slf4j both use the same package name - > org.apache.logging.log4j.slf4j. This will remain the same as it will prevent > them both from being loaded at the same time. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2056) Modularize Log4j as automatic modules
[ https://issues.apache.org/jira/browse/LOG4J2-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202635#comment-16202635 ] Ralph Goers commented on LOG4J2-2056: - [~njbartlett] Thanks for jumping in. The options are listed in the link Stephen created - https://github.com/jodastephen/jpms-module-names/wiki/Logging-APIs. Basically, it is a choice on whether to have multiple modules that implement the same thing all use the same module name or whether they should all be unique. SLF4J and the Log4j 2 API can each be bound to one of many logging implementations. So should Logback use org.slf4j.impl as its module name or Logback's package - ch.qos.logback. Likewise, Log4j's implementation could either be org.apache.logging.log4j.impl (a generic name) or org.apache.logging.log4j.core (the actual package name of the implementation). In the case of SLF4J, Log4j provides a "binding" that causes SLF4J to use Log4j. We would either also use org.slf4j.impl for that or we would use org.apache.logging.log4j.slf4j. Right now these are all automatic modules - we can't turn them into "real" modules until all the dependencies have declared names - but we need to have the names be right on the first try. Unfortunately, JPMS doesn't provide any guidance on any of this. It is only with the help of folks like you and Stephen that Java frameworks are making any progress at all. > Modularize Log4j as automatic modules > - > > Key: LOG4J2-2056 > URL: https://issues.apache.org/jira/browse/LOG4J2-2056 > Project: Log4j 2 > Issue Type: New Feature >Affects Versions: 2.9.1 >Reporter: Ralph Goers >Assignee: Ralph Goers > > To fully support Java 9 all Log4j jars must (at least) be packaged as > automatic modules. We should, as much as possible, follow the recommendations > at http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html. Given > that the module names would be: > ||Artifact ID ||Module name|| > |log4j-api|org.apache.logging.log4j| > |log4j-core|org.apache.logging.log4j.core| > |log4j-1.2-api|org.apache.log4j| > |log4j-appserver|org.apache.logging.log4j.appserver| > |log4j-flume-ng|org.apache.logging.log4j.flume| > |log4j-iostreams|org.apache.logging.log4j.iostreams| > |log4j-jcl|org.apache.logging.log4j.jcl| > |log4j-jmx-gui|org.apache.logging.log4j.jmx.gui| > |log4j-jul|org.apache.logging.log4j.jul| > |log4j-nosql|org.apache.logging.log4j.nosql| > |log4j-osgi|org.apache.logging.log4j.osgi| > |log4j-sl4j-impl|org.apache.logging.log4j.slf4j.impl*| > |log4j-to-slf4j|org.apache.logging.log4j.to.slf4j| > |log4j-taglib|org.apache.logging.log4j.taglib| > |log4j-web|org.apache.logging.log4j.web| > # log4j-liquibase uses a package name outside the org.apache.logging.log4j > namespace so is not modularized. > # log4j-slf4j-impl cannot currently be modularized until the binding is > modified. It cannot have classes in the org.slf4j namespace. > # log4j-slf4j-impl and log4j-to-slf4j both use the same package name - > org.apache.logging.log4j.slf4j. This will remain the same as it will prevent > them both from being loaded at the same time. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2056) Modularize Log4j as automatic modules
[ https://issues.apache.org/jira/browse/LOG4J2-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202609#comment-16202609 ] Neil Bartlett commented on LOG4J2-2056: --- Joining this thread as I see my name being invoked... I did point out to Stephen on Twitter that my OSGi experience is in general not that useful in resolving this issue because in OSGi we don't have this problem. >From a quick scan of the thread I don't know what the two options being >debated are. What seems clear to me is that, under JPMS, the module name is >"API". Therefore if two artifacts provide the same API then they must provide >the same module name. > Modularize Log4j as automatic modules > - > > Key: LOG4J2-2056 > URL: https://issues.apache.org/jira/browse/LOG4J2-2056 > Project: Log4j 2 > Issue Type: New Feature >Affects Versions: 2.9.1 >Reporter: Ralph Goers >Assignee: Ralph Goers > > To fully support Java 9 all Log4j jars must (at least) be packaged as > automatic modules. We should, as much as possible, follow the recommendations > at http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html. Given > that the module names would be: > ||Artifact ID ||Module name|| > |log4j-api|org.apache.logging.log4j| > |log4j-core|org.apache.logging.log4j.core| > |log4j-1.2-api|org.apache.log4j| > |log4j-appserver|org.apache.logging.log4j.appserver| > |log4j-flume-ng|org.apache.logging.log4j.flume| > |log4j-iostreams|org.apache.logging.log4j.iostreams| > |log4j-jcl|org.apache.logging.log4j.jcl| > |log4j-jmx-gui|org.apache.logging.log4j.jmx.gui| > |log4j-jul|org.apache.logging.log4j.jul| > |log4j-nosql|org.apache.logging.log4j.nosql| > |log4j-osgi|org.apache.logging.log4j.osgi| > |log4j-sl4j-impl|org.apache.logging.log4j.slf4j.impl*| > |log4j-to-slf4j|org.apache.logging.log4j.to.slf4j| > |log4j-taglib|org.apache.logging.log4j.taglib| > |log4j-web|org.apache.logging.log4j.web| > # log4j-liquibase uses a package name outside the org.apache.logging.log4j > namespace so is not modularized. > # log4j-slf4j-impl cannot currently be modularized until the binding is > modified. It cannot have classes in the org.slf4j namespace. > # log4j-slf4j-impl and log4j-to-slf4j both use the same package name - > org.apache.logging.log4j.slf4j. This will remain the same as it will prevent > them both from being loaded at the same time. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2062) Add possibility of sending the key of a message to Kafka using KafkaAppender
[ https://issues.apache.org/jira/browse/LOG4J2-2062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202534#comment-16202534 ] Jorge Sanchez commented on LOG4J2-2062: --- Thank you for your comments I really appreciate them (and sorry for not implementing them before). I have implemented the changes to include the key as an attribute, and now I will start working on the lookups. > Add possibility of sending the key of a message to Kafka using KafkaAppender > > > Key: LOG4J2-2062 > URL: https://issues.apache.org/jira/browse/LOG4J2-2062 > Project: Log4j 2 > Issue Type: Improvement > Components: Appenders >Affects Versions: 2.9.0, 2.9.1 >Reporter: Jorge Sanchez >Assignee: Mikael Ståldal >Priority: Minor > > When using the KafkaAppender the KafkaManager only sends the value of a > message to a Kafka topic. > It could be useful to be able to assign a value to the key of that message > via configuration instead of having it null. > Check > https://github.com/apache/logging-log4j2/blob/master/log4j-core/src/main/java/org/apache/logging/log4j/core/appender/mom/kafka/KafkaManager.java#L99 > Updated with link to the PR: https://github.com/apache/logging-log4j2/pull/112 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2056) Modularize Log4j as automatic modules
[ https://issues.apache.org/jira/browse/LOG4J2-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202397#comment-16202397 ] Ralph Goers commented on LOG4J2-2056: - Yes, an empty Automatic-Module-Name. That seems possibly better to me as it will hopefully result in an error rather than a module name based on the jar file name. I don't follow Neil Bartlett and rarely look at Twitter, so I have no idea why we have to go with option 2. A link would help. > Modularize Log4j as automatic modules > - > > Key: LOG4J2-2056 > URL: https://issues.apache.org/jira/browse/LOG4J2-2056 > Project: Log4j 2 > Issue Type: New Feature >Affects Versions: 2.9.1 >Reporter: Ralph Goers >Assignee: Ralph Goers > > To fully support Java 9 all Log4j jars must (at least) be packaged as > automatic modules. We should, as much as possible, follow the recommendations > at http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html. Given > that the module names would be: > ||Artifact ID ||Module name|| > |log4j-api|org.apache.logging.log4j| > |log4j-core|org.apache.logging.log4j.core| > |log4j-1.2-api|org.apache.log4j| > |log4j-appserver|org.apache.logging.log4j.appserver| > |log4j-flume-ng|org.apache.logging.log4j.flume| > |log4j-iostreams|org.apache.logging.log4j.iostreams| > |log4j-jcl|org.apache.logging.log4j.jcl| > |log4j-jmx-gui|org.apache.logging.log4j.jmx.gui| > |log4j-jul|org.apache.logging.log4j.jul| > |log4j-nosql|org.apache.logging.log4j.nosql| > |log4j-osgi|org.apache.logging.log4j.osgi| > |log4j-sl4j-impl|org.apache.logging.log4j.slf4j.impl*| > |log4j-to-slf4j|org.apache.logging.log4j.to.slf4j| > |log4j-taglib|org.apache.logging.log4j.taglib| > |log4j-web|org.apache.logging.log4j.web| > # log4j-liquibase uses a package name outside the org.apache.logging.log4j > namespace so is not modularized. > # log4j-slf4j-impl cannot currently be modularized until the binding is > modified. It cannot have classes in the org.slf4j namespace. > # log4j-slf4j-impl and log4j-to-slf4j both use the same package name - > org.apache.logging.log4j.slf4j. This will remain the same as it will prevent > them both from being loaded at the same time. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2072) Support TLS configuration through FlumeAppender
[ https://issues.apache.org/jira/browse/LOG4J2-2072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202304#comment-16202304 ] Matt Sicker commented on LOG4J2-2072: - Take a look at the TLS/SSL support classes in core for some potentially useful integration points: https://github.com/apache/logging-log4j2/tree/master/log4j-core/src/main/java/org/apache/logging/log4j/core/net/ssl > Support TLS configuration through FlumeAppender > --- > > Key: LOG4J2-2072 > URL: https://issues.apache.org/jira/browse/LOG4J2-2072 > Project: Log4j 2 > Issue Type: Bug > Components: Flume Appender >Affects Versions: 2.9.1 >Reporter: Frank Swanson > > When using the FlumeAppnder with a FlumeAvroManager it would be nice to be > able to pass some properties through to the connect method for the RpcClient > to support SSL configuration. > The required properties to support the configuration are ~ > properties[0] = > Property.createProperty(RpcClientConfigurationConstants.CONFIG_TRUST_ALL_CERTS, > "false"); > properties[1] = > Property.createProperty(RpcClientConfigurationConstants.CONFIG_SSL, "true"); > properties[2] = > Property.createProperty(RpcClientConfigurationConstants.CONFIG_TRUSTSTORE, > path_to_truststore); > properties[3] = > Property.createProperty(RpcClientConfigurationConstants.CONFIG_TRUSTSTORE_PASSWORD, > super_secret); > properties[4] = > Property.createProperty(RpcClientConfigurationConstants.CONFIG_TRUSTSTORE_TYPE, > "JKS"); > I am happy to provide a PR for this feature if supported. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2072) Support TLS configuration through FlumeAppender
[ https://issues.apache.org/jira/browse/LOG4J2-2072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202207#comment-16202207 ] Gary Gregory commented on LOG4J2-2072: -- Thank you for helping out. Please do not forget unit tests. > Support TLS configuration through FlumeAppender > --- > > Key: LOG4J2-2072 > URL: https://issues.apache.org/jira/browse/LOG4J2-2072 > Project: Log4j 2 > Issue Type: Bug > Components: Flume Appender >Affects Versions: 2.9.1 >Reporter: Frank Swanson > > When using the FlumeAppnder with a FlumeAvroManager it would be nice to be > able to pass some properties through to the connect method for the RpcClient > to support SSL configuration. > The required properties to support the configuration are ~ > properties[0] = > Property.createProperty(RpcClientConfigurationConstants.CONFIG_TRUST_ALL_CERTS, > "false"); > properties[1] = > Property.createProperty(RpcClientConfigurationConstants.CONFIG_SSL, "true"); > properties[2] = > Property.createProperty(RpcClientConfigurationConstants.CONFIG_TRUSTSTORE, > path_to_truststore); > properties[3] = > Property.createProperty(RpcClientConfigurationConstants.CONFIG_TRUSTSTORE_PASSWORD, > super_secret); > properties[4] = > Property.createProperty(RpcClientConfigurationConstants.CONFIG_TRUSTSTORE_TYPE, > "JKS"); > I am happy to provide a PR for this feature if supported. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Reopened] (LOG4J2-1216) Nested pattern layout options broken
[
https://issues.apache.org/jira/browse/LOG4J2-1216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory reopened LOG4J2-1216:
--
> Nested pattern layout options broken
>
>
> Key: LOG4J2-1216
> URL: https://issues.apache.org/jira/browse/LOG4J2-1216
> Project: Log4j 2
> Issue Type: Bug
> Components: Pattern Converters
>Affects Versions: 2.4.1, 2.9.1
>Reporter: Thies Wellpott
> Labels: easyfix
> Fix For: 2.9.2
>
>
> Parsing the "deeply" nested PatternLayout
> {code}
> %maxLen{[XXX, ${hostName}, ${web:contextPath}] %p: %c{1} - %m%notEmpty{
> =>%ex{short}}}{160}
> {code}
> (with %maxLen being a custom Converter)
> results in wrong parsing.
> Patternparser.extractOptions() gets the nesting wrong.
> Solution:
> {code}
> private static int extractOptions(final String pattern, final int start,
> final List options) {
> int i = start;
> while (i < pattern.length() && pattern.charAt(i) == '{') {
> i++; // skip opening "{"
> final int begin = i; // position of first real char
> int depth = 1;// already inside one level
> while (depth > 0 && i < pattern.length()) {
> char c = pattern.charAt(i);
> if (c == '{') {
> depth++;
> } else if (c == '}') {
> depth--;
> // TODO(?) maybe escaping of { and } with \ or %
> }
> i++;
> } // while
> if (depth > 0) { // option not closed, continue with pattern
> on opening "{"
> return begin-1;
> }
> options.add(pattern.substring(begin, i-1));
> } // while
> return i;
> }
> {code}
> This should also be faster than the current implementation because the
> pattern ist only walked once, not multiple times with indexOf().
> (LOG4J2-107 is a similar but old bug)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LOG4J2-2056) Modularize Log4j as automatic modules
[ https://issues.apache.org/jira/browse/LOG4J2-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202165#comment-16202165 ] Stephen Colebourne commented on LOG4J2-2056: 1. Do you mean having an empty Automatic-Module-Name? Not sure what would happen then. 2. Given what you say about Log4J2 and what Neil Bartlett said on Twitter re module names, I think we have to go with option 2. What bothers me is that there is the potential for people to mistakenly add an implementation module as a dependency of a library-style module and release that. Once that happens, there is no "exclude" as in maven so there is no way to get rid of that implementation and replace it by the one you actually want. (This is why option 1 appeals, as mistake have less serious impact). 3. Agreed - everyone would have to have the same naming strategy. > Modularize Log4j as automatic modules > - > > Key: LOG4J2-2056 > URL: https://issues.apache.org/jira/browse/LOG4J2-2056 > Project: Log4j 2 > Issue Type: New Feature >Affects Versions: 2.9.1 >Reporter: Ralph Goers >Assignee: Ralph Goers > > To fully support Java 9 all Log4j jars must (at least) be packaged as > automatic modules. We should, as much as possible, follow the recommendations > at http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html. Given > that the module names would be: > ||Artifact ID ||Module name|| > |log4j-api|org.apache.logging.log4j| > |log4j-core|org.apache.logging.log4j.core| > |log4j-1.2-api|org.apache.log4j| > |log4j-appserver|org.apache.logging.log4j.appserver| > |log4j-flume-ng|org.apache.logging.log4j.flume| > |log4j-iostreams|org.apache.logging.log4j.iostreams| > |log4j-jcl|org.apache.logging.log4j.jcl| > |log4j-jmx-gui|org.apache.logging.log4j.jmx.gui| > |log4j-jul|org.apache.logging.log4j.jul| > |log4j-nosql|org.apache.logging.log4j.nosql| > |log4j-osgi|org.apache.logging.log4j.osgi| > |log4j-sl4j-impl|org.apache.logging.log4j.slf4j.impl*| > |log4j-to-slf4j|org.apache.logging.log4j.to.slf4j| > |log4j-taglib|org.apache.logging.log4j.taglib| > |log4j-web|org.apache.logging.log4j.web| > # log4j-liquibase uses a package name outside the org.apache.logging.log4j > namespace so is not modularized. > # log4j-slf4j-impl cannot currently be modularized until the binding is > modified. It cannot have classes in the org.slf4j namespace. > # log4j-slf4j-impl and log4j-to-slf4j both use the same package name - > org.apache.logging.log4j.slf4j. This will remain the same as it will prevent > them both from being loaded at the same time. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2072) Support TLS configuration through FlumeAppender
[ https://issues.apache.org/jira/browse/LOG4J2-2072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202061#comment-16202061 ] Frank Swanson commented on LOG4J2-2072: --- I will put it together shortly(Hopefully this weekend). Thank you. > Support TLS configuration through FlumeAppender > --- > > Key: LOG4J2-2072 > URL: https://issues.apache.org/jira/browse/LOG4J2-2072 > Project: Log4j 2 > Issue Type: Bug > Components: Flume Appender >Affects Versions: 2.9.1 >Reporter: Frank Swanson > > When using the FlumeAppnder with a FlumeAvroManager it would be nice to be > able to pass some properties through to the connect method for the RpcClient > to support SSL configuration. > The required properties to support the configuration are ~ > properties[0] = > Property.createProperty(RpcClientConfigurationConstants.CONFIG_TRUST_ALL_CERTS, > "false"); > properties[1] = > Property.createProperty(RpcClientConfigurationConstants.CONFIG_SSL, "true"); > properties[2] = > Property.createProperty(RpcClientConfigurationConstants.CONFIG_TRUSTSTORE, > path_to_truststore); > properties[3] = > Property.createProperty(RpcClientConfigurationConstants.CONFIG_TRUSTSTORE_PASSWORD, > super_secret); > properties[4] = > Property.createProperty(RpcClientConfigurationConstants.CONFIG_TRUSTSTORE_TYPE, > "JKS"); > I am happy to provide a PR for this feature if supported. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (LOG4J2-1216) Nested pattern layout options broken
[
https://issues.apache.org/jira/browse/LOG4J2-1216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16201806#comment-16201806
]
Georg Friedrich edited comment on LOG4J2-1216 at 10/12/17 11:23 AM:
Hi guys,
you just introduced an endless parsing of broken patterns like "%d{". If you're
using a pattern like this one, your application will never boot up, as it hangs
forever in the parsing routine.
As you can see I created a patch and added some tests (and also did some minor
cleanup of the test class).
[~garydgregory] Please reopen the ticket to fix it properly. Thank you.
was (Author: gfriedrich):
Hi guys,
you just introduced an endless parsing of broken patterns like "%d{". If you
using a pattern like this one, your application will never boot up, as it hangs
forever in the parsing routine.
As you can see I created a patch and added some tests (and also did some minor
cleanup of the test class).
[~garydgregory] Please reopen the ticket to fix it properly. Thank you.
> Nested pattern layout options broken
>
>
> Key: LOG4J2-1216
> URL: https://issues.apache.org/jira/browse/LOG4J2-1216
> Project: Log4j 2
> Issue Type: Bug
> Components: Pattern Converters
>Affects Versions: 2.4.1, 2.9.1
>Reporter: Thies Wellpott
> Labels: easyfix
> Fix For: 2.9.2
>
>
> Parsing the "deeply" nested PatternLayout
> {code}
> %maxLen{[XXX, ${hostName}, ${web:contextPath}] %p: %c{1} - %m%notEmpty{
> =>%ex{short}}}{160}
> {code}
> (with %maxLen being a custom Converter)
> results in wrong parsing.
> Patternparser.extractOptions() gets the nesting wrong.
> Solution:
> {code}
> private static int extractOptions(final String pattern, final int start,
> final List options) {
> int i = start;
> while (i < pattern.length() && pattern.charAt(i) == '{') {
> i++; // skip opening "{"
> final int begin = i; // position of first real char
> int depth = 1;// already inside one level
> while (depth > 0 && i < pattern.length()) {
> char c = pattern.charAt(i);
> if (c == '{') {
> depth++;
> } else if (c == '}') {
> depth--;
> // TODO(?) maybe escaping of { and } with \ or %
> }
> i++;
> } // while
> if (depth > 0) { // option not closed, continue with pattern
> on opening "{"
> return begin-1;
> }
> options.add(pattern.substring(begin, i-1));
> } // while
> return i;
> }
> {code}
> This should also be faster than the current implementation because the
> pattern ist only walked once, not multiple times with indexOf().
> (LOG4J2-107 is a similar but old bug)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LOG4J2-1216) Nested pattern layout options broken
[
https://issues.apache.org/jira/browse/LOG4J2-1216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16201806#comment-16201806
]
Georg Friedrich commented on LOG4J2-1216:
-
Hi guys,
you just introduced an endless parsing of broken patterns like "%d{". If you
using a pattern like this one, your application will never boot up, as it hangs
forever in the parsing routine.
As you can see I created a patch and added some tests (and also did some minor
cleanup of the test class).
[~garydgregory] Please reopen the ticket to fix it properly. Thank you.
> Nested pattern layout options broken
>
>
> Key: LOG4J2-1216
> URL: https://issues.apache.org/jira/browse/LOG4J2-1216
> Project: Log4j 2
> Issue Type: Bug
> Components: Pattern Converters
>Affects Versions: 2.4.1, 2.9.1
>Reporter: Thies Wellpott
> Labels: easyfix
> Fix For: 2.9.2
>
>
> Parsing the "deeply" nested PatternLayout
> {code}
> %maxLen{[XXX, ${hostName}, ${web:contextPath}] %p: %c{1} - %m%notEmpty{
> =>%ex{short}}}{160}
> {code}
> (with %maxLen being a custom Converter)
> results in wrong parsing.
> Patternparser.extractOptions() gets the nesting wrong.
> Solution:
> {code}
> private static int extractOptions(final String pattern, final int start,
> final List options) {
> int i = start;
> while (i < pattern.length() && pattern.charAt(i) == '{') {
> i++; // skip opening "{"
> final int begin = i; // position of first real char
> int depth = 1;// already inside one level
> while (depth > 0 && i < pattern.length()) {
> char c = pattern.charAt(i);
> if (c == '{') {
> depth++;
> } else if (c == '}') {
> depth--;
> // TODO(?) maybe escaping of { and } with \ or %
> }
> i++;
> } // while
> if (depth > 0) { // option not closed, continue with pattern
> on opening "{"
> return begin-1;
> }
> options.add(pattern.substring(begin, i-1));
> } // while
> return i;
> }
> {code}
> This should also be faster than the current implementation because the
> pattern ist only walked once, not multiple times with indexOf().
> (LOG4J2-107 is a similar but old bug)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LOG4J2-1216) Nested pattern layout options broken
[
https://issues.apache.org/jira/browse/LOG4J2-1216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16201802#comment-16201802
]
ASF GitHub Bot commented on LOG4J2-1216:
GitHub user GFriedrich opened a pull request:
https://github.com/apache/logging-log4j2/pull/116
[LOG4J2-1216] fix PatternParser for patterns without closing brackets
This fixes an endless parsing for broken patterns without closing brackets
like "%d{" or patterns where closing brackets only exist for parts of the
pattern before a "{" like "}%d{".
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/GFriedrich/logging-log4j2 master
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/logging-log4j2/pull/116.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #116
commit 92ef7be3cb7133f00bcd39413e08444897208992
Author: Georg Friedrich <magicb...@gmx.de>
Date: 2017-10-12T11:13:55Z
[LOG4J2-1216] fix PatternParser for patterns without closing brackets
> Nested pattern layout options broken
>
>
> Key: LOG4J2-1216
> URL: https://issues.apache.org/jira/browse/LOG4J2-1216
> Project: Log4j 2
> Issue Type: Bug
> Components: Pattern Converters
>Affects Versions: 2.4.1, 2.9.1
>Reporter: Thies Wellpott
> Labels: easyfix
> Fix For: 2.9.2
>
>
> Parsing the "deeply" nested PatternLayout
> {code}
> %maxLen{[XXX, ${hostName}, ${web:contextPath}] %p: %c{1} - %m%notEmpty{
> =>%ex{short}}}{160}
> {code}
> (with %maxLen being a custom Converter)
> results in wrong parsing.
> Patternparser.extractOptions() gets the nesting wrong.
> Solution:
> {code}
> private static int extractOptions(final String pattern, final int start,
> final List options) {
> int i = start;
> while (i < pattern.length() && pattern.charAt(i) == '{') {
> i++; // skip opening "{"
> final int begin = i; // position of first real char
> int depth = 1;// already inside one level
> while (depth > 0 && i < pattern.length()) {
> char c = pattern.charAt(i);
> if (c == '{') {
> depth++;
> } else if (c == '}') {
> depth--;
> // TODO(?) maybe escaping of { and } with \ or %
> }
> i++;
> } // while
> if (depth > 0) { // option not closed, continue with pattern
> on opening "{"
> return begin-1;
> }
> options.add(pattern.substring(begin, i-1));
> } // while
> return i;
> }
> {code}
> This should also be faster than the current implementation because the
> pattern ist only walked once, not multiple times with indexOf().
> (LOG4J2-107 is a similar but old bug)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LOG4J2-1982) Log4j-config.xsd only allows one AppenderRef element for each Logger element
[
https://issues.apache.org/jira/browse/LOG4J2-1982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16201746#comment-16201746
]
Patrick Lucas commented on LOG4J2-1982:
---
Shouldn't this have {{minOccurs="0"}} since omitting the AppenderRef is
allowed? (in which case it delegates to the root logger, I think)
> Log4j-config.xsd only allows one AppenderRef element for each Logger element
>
>
> Key: LOG4J2-1982
> URL: https://issues.apache.org/jira/browse/LOG4J2-1982
> Project: Log4j 2
> Issue Type: Bug
> Components: Configurators
>Affects Versions: 2.8.2
> Environment: Alle environments
>Reporter: Christoph Lembeck
> Fix For: 2.9.0
>
>
> The xsd schema definition for the log4j configuration allow only one
> AppenderRef per Logger. The definition of the Logger element is as follows
> {code:xml}
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> Comparing this to the Definition of the root Logger we see a sequence of
> multiple Appender
> Ref elements to be allowed.
> {code:xml}
>
>
> minOccurs="1" maxOccurs="unbounded"/>
>
>
>
> {code}
> With this configuration it is not possible to define a specific Logger, that
> shows infos and errors to the console and writes only the errors in a log
> file, since there can only be one appender defined for that logger.
> Please modify the xsd file to allow mutliple AppenderRef elements per Logger.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LOG4J2-2072) Support TLS configuration through FlumeAppender
[ https://issues.apache.org/jira/browse/LOG4J2-2072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16201429#comment-16201429 ] Ralph Goers commented on LOG4J2-2072: - Patches are always welcome. > Support TLS configuration through FlumeAppender > --- > > Key: LOG4J2-2072 > URL: https://issues.apache.org/jira/browse/LOG4J2-2072 > Project: Log4j 2 > Issue Type: Bug > Components: Flume Appender >Affects Versions: 2.9.1 >Reporter: Frank Swanson > > When using the FlumeAppnder with a FlumeAvroManager it would be nice to be > able to pass some properties through to the connect method for the RpcClient > to support SSL configuration. > The required properties to support the configuration are ~ > properties[0] = > Property.createProperty(RpcClientConfigurationConstants.CONFIG_TRUST_ALL_CERTS, > "false"); > properties[1] = > Property.createProperty(RpcClientConfigurationConstants.CONFIG_SSL, "true"); > properties[2] = > Property.createProperty(RpcClientConfigurationConstants.CONFIG_TRUSTSTORE, > path_to_truststore); > properties[3] = > Property.createProperty(RpcClientConfigurationConstants.CONFIG_TRUSTSTORE_PASSWORD, > super_secret); > properties[4] = > Property.createProperty(RpcClientConfigurationConstants.CONFIG_TRUSTSTORE_TYPE, > "JKS"); > I am happy to provide a PR for this feature if supported. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (LOG4J2-2072) Support TLS configuration through FlumeAppender
[ https://issues.apache.org/jira/browse/LOG4J2-2072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frank Swanson updated LOG4J2-2072: -- Description: When using the FlumeAppnder with a FlumeAvroManager it would be nice to be able to pass some properties through to the connect method for the RpcClient to support SSL configuration. The required properties to support the configuration are ~ properties[0] = Property.createProperty(RpcClientConfigurationConstants.CONFIG_TRUST_ALL_CERTS, "false"); properties[1] = Property.createProperty(RpcClientConfigurationConstants.CONFIG_SSL, "true"); properties[2] = Property.createProperty(RpcClientConfigurationConstants.CONFIG_TRUSTSTORE, path_to_truststore); properties[3] = Property.createProperty(RpcClientConfigurationConstants.CONFIG_TRUSTSTORE_PASSWORD, super_secret); properties[4] = Property.createProperty(RpcClientConfigurationConstants.CONFIG_TRUSTSTORE_TYPE, "JKS"); I am happy to provide a PR for this feature if supported. was: When using the FlumeAppnder with a FlumeAvroManager it would be nice to be able to pass some properties through to the connect method for the RpcClient to support SSL configuration. I am happy to provide a PR for this feature if supported. > Support TLS configuration through FlumeAppender > --- > > Key: LOG4J2-2072 > URL: https://issues.apache.org/jira/browse/LOG4J2-2072 > Project: Log4j 2 > Issue Type: Bug > Components: Flume Appender >Affects Versions: 2.9.1 >Reporter: Frank Swanson > > When using the FlumeAppnder with a FlumeAvroManager it would be nice to be > able to pass some properties through to the connect method for the RpcClient > to support SSL configuration. > The required properties to support the configuration are ~ > properties[0] = > Property.createProperty(RpcClientConfigurationConstants.CONFIG_TRUST_ALL_CERTS, > "false"); > properties[1] = > Property.createProperty(RpcClientConfigurationConstants.CONFIG_SSL, "true"); > properties[2] = > Property.createProperty(RpcClientConfigurationConstants.CONFIG_TRUSTSTORE, > path_to_truststore); > properties[3] = > Property.createProperty(RpcClientConfigurationConstants.CONFIG_TRUSTSTORE_PASSWORD, > super_secret); > properties[4] = > Property.createProperty(RpcClientConfigurationConstants.CONFIG_TRUSTSTORE_TYPE, > "JKS"); > I am happy to provide a PR for this feature if supported. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (LOG4J2-2072) Support TLS configuration through FlumeAppender
[ https://issues.apache.org/jira/browse/LOG4J2-2072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frank Swanson updated LOG4J2-2072: -- Description: When using the FlumeAppnder with a FlumeAvroManager it would be nice to be able to pass some properties through to the connect method for the RpcClient to support SSL configuration. I am happy to provide a PR for this feature if supported. was: When using the FlumeAppnder with a FlumeAvroManager it would be nice to be able to pass some properties through to support SSL configuration. I am happy to provide a PR for this feature if supported. > Support TLS configuration through FlumeAppender > --- > > Key: LOG4J2-2072 > URL: https://issues.apache.org/jira/browse/LOG4J2-2072 > Project: Log4j 2 > Issue Type: Bug > Components: Flume Appender >Affects Versions: 2.9.1 >Reporter: Frank Swanson > > When using the FlumeAppnder with a FlumeAvroManager it would be nice to be > able to pass some properties through to the connect method for the RpcClient > to support SSL configuration. > I am happy to provide a PR for this feature if supported. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (LOG4J2-2072) Support TLS configuration through FlumeAppender
Frank Swanson created LOG4J2-2072: - Summary: Support TLS configuration through FlumeAppender Key: LOG4J2-2072 URL: https://issues.apache.org/jira/browse/LOG4J2-2072 Project: Log4j 2 Issue Type: Bug Components: Flume Appender Affects Versions: 2.9.1 Reporter: Frank Swanson When using the FlumeAppnder with a FlumeAvroManager it would be nice to be able to pass some properties through to support SSL configuration. I am happy to provide a PR for this feature if supported. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2068) Can't set monitorInterval for composite XML configuration.
[
https://issues.apache.org/jira/browse/LOG4J2-2068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16201184#comment-16201184
]
Robert Haycock commented on LOG4J2-2068:
I created a branch but can't push, keep getting authentication failed. Here's a
better unit test...
{code}
@Test
public void testConfigReloaded() {
final LoggerContextRule lcr = new
LoggerContextRule("log4j-console.xml,log4j-console.xml");
final Statement test = new Statement() {
@Override
public void evaluate() throws Throwable {
final CompositeConfiguration config = (CompositeConfiguration)
lcr.getConfiguration();
Assert.assertNotNull(config);
// Register a listener to listen for errors
final AtomicInteger i = new AtomicInteger(0);
StatusLogger.getLogger().registerListener(new StatusListener() {
@Override
public void close()
throws IOException {
}
@Override
public void log(StatusData data) {
i.incrementAndGet();
}
@Override
public Level getStatusLevel() {
return Level.ERROR;
}
});
// onChange() would be called if files were modified
lcr.getLoggerContext().onChange(config);
assertTrue("There should be no errors logged when
reconfiguring", i.get() == 0);
}
};
runTest(lcr, test);
}
{code}
> Can't set monitorInterval for composite XML configuration.
> --
>
> Key: LOG4J2-2068
> URL: https://issues.apache.org/jira/browse/LOG4J2-2068
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.9.1
>Reporter: Robert Haycock
> Fix For: 2.9.2
>
> Attachments: patch_2068.diff
>
>
> When trying to combine a composite configuration with automatic reload, it
> fails to reload.
> When an {{XmlConfiguration}} is reloaded it calls
> {{XmlConfiguration.reconfigure()}} which sets the {{rootElement}} field, and
> everything is fine.
> When a {{CompositeConfiguration}} is reloaded, it doesn't call
> {{reconfigure()}} on the {{XmlConfigurations}}. This means when it tries to
> start the config {{XmlConfiguration.setup()}} is called and {{rootElement}}
> is null, resulting in an error message "No logging configuration".
> End result is the config isn't loaded and there's no more logging.
> To reproduce, it doesn't matter what is in the configurations. Just need at
> least 2 XML configs in the {{log4j.configurationFile}} property and the
> {{monitorInterval}} set.
> (Ps. my first ticket)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LOG4J2-2071) Add org.apache.logging.log4j.core.config.composite.CompositeConfiguration#toString()
[ https://issues.apache.org/jira/browse/LOG4J2-2071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16201065#comment-16201065 ] Gary Gregory commented on LOG4J2-2071: -- This closes #114. > Add > org.apache.logging.log4j.core.config.composite.CompositeConfiguration#toString() > > > Key: LOG4J2-2071 > URL: https://issues.apache.org/jira/browse/LOG4J2-2071 > Project: Log4j 2 > Issue Type: Improvement > Components: Core >Reporter: Gary Gregory >Assignee: Gary Gregory > Fix For: 2.9.2 > > > Add > org.apache.logging.log4j.core.config.composite.CompositeConfiguration#toString() -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2071) Add org.apache.logging.log4j.core.config.composite.CompositeConfiguration#toString()
[ https://issues.apache.org/jira/browse/LOG4J2-2071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16201062#comment-16201062 ] ASF GitHub Bot commented on LOG4J2-2071: Github user garydgregory commented on the issue: https://github.com/apache/logging-log4j2/pull/114 I provided a different implementation. Tracking with https://issues.apache.org/jira/browse/LOG4J2-2071 > Add > org.apache.logging.log4j.core.config.composite.CompositeConfiguration#toString() > > > Key: LOG4J2-2071 > URL: https://issues.apache.org/jira/browse/LOG4J2-2071 > Project: Log4j 2 > Issue Type: Improvement > Components: Core >Reporter: Gary Gregory >Assignee: Gary Gregory > Fix For: 2.9.2 > > > Add > org.apache.logging.log4j.core.config.composite.CompositeConfiguration#toString() -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2071) Add org.apache.logging.log4j.core.config.composite.CompositeConfiguration#toString()
[ https://issues.apache.org/jira/browse/LOG4J2-2071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16201061#comment-16201061 ] ASF subversion and git services commented on LOG4J2-2071: - Commit 8b6442442ae1f8c58eea185a958e73831274ce88 in logging-log4j2's branch refs/heads/master from [~garydgregory] [ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=8b64424 ] [LOG4J2-2071] Add org.apache.logging.log4j.core.config.composite.CompositeConfiguration#toString(). > Add > org.apache.logging.log4j.core.config.composite.CompositeConfiguration#toString() > > > Key: LOG4J2-2071 > URL: https://issues.apache.org/jira/browse/LOG4J2-2071 > Project: Log4j 2 > Issue Type: Improvement > Components: Core >Reporter: Gary Gregory >Assignee: Gary Gregory > Fix For: 2.9.2 > > > Add > org.apache.logging.log4j.core.config.composite.CompositeConfiguration#toString() -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (LOG4J2-2071) Add org.apache.logging.log4j.core.config.composite.CompositeConfiguration#toString()
Gary Gregory created LOG4J2-2071: Summary: Add org.apache.logging.log4j.core.config.composite.CompositeConfiguration#toString() Key: LOG4J2-2071 URL: https://issues.apache.org/jira/browse/LOG4J2-2071 Project: Log4j 2 Issue Type: Improvement Components: Core Reporter: Gary Gregory Assignee: Gary Gregory Fix For: 2.9.2 Add org.apache.logging.log4j.core.config.composite.CompositeConfiguration#toString() -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2036) CompositeConfiguration with monitorInterval fails to reload full configuration
[ https://issues.apache.org/jira/browse/LOG4J2-2036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16201047#comment-16201047 ] ASF GitHub Bot commented on LOG4J2-2036: Github user asfgit closed the pull request at: https://github.com/apache/logging-log4j2/pull/115 > CompositeConfiguration with monitorInterval fails to reload full configuration > -- > > Key: LOG4J2-2036 > URL: https://issues.apache.org/jira/browse/LOG4J2-2036 > Project: Log4j 2 > Issue Type: Bug > Components: Configurators >Affects Versions: 2.9.0 > Environment: I have pushed a very simple repro here: > https://github.com/cakofony/log4j2-composite-config-repro >Reporter: Carter Douglas Kozak > > Steps to reproduce: > 1. Create two configuration files, in my case I use a "default" embedded > configuration on the classpath, and a second configuration on disk for > overrides (this configuration uses monitorInterval=30). > 2. Configurator.initialize(null, classLoader, ImmutableList.of(defaultUri, > diskUri), null) > 3. On initial startup, the two configurations are merged perfectly, > everything works as expected. > 4. Modify the on disk (override) configuration while the application is > running, the failure is most apparent if I update a logger to reference an > appender only defined in the "default" configuration. Reconfiguration > executes but only using the file on disk, as though the first configuration > has disappeared. > This is a regression from 2.8.2, so I have rolled back to that version. > Unfortunately 2.8.2 is affected by LOG4J2-1912 and complains with misleading > warning messages so I've had to update the status logger to error level from > info. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2036) CompositeConfiguration with monitorInterval fails to reload full configuration
[ https://issues.apache.org/jira/browse/LOG4J2-2036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16201046#comment-16201046 ] ASF subversion and git services commented on LOG4J2-2036: - Commit d647c0b1ac0bdee60f392083bd523a83d765e47e in logging-log4j2's branch refs/heads/master from [~garydgregory] [ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=d647c0b ] [LOG4J2-2036] CompositeConfiguration supports Reconfiguration. Full build with 'mvn clean install' OK. This closes #115. > CompositeConfiguration with monitorInterval fails to reload full configuration > -- > > Key: LOG4J2-2036 > URL: https://issues.apache.org/jira/browse/LOG4J2-2036 > Project: Log4j 2 > Issue Type: Bug > Components: Configurators >Affects Versions: 2.9.0 > Environment: I have pushed a very simple repro here: > https://github.com/cakofony/log4j2-composite-config-repro >Reporter: Carter Douglas Kozak > > Steps to reproduce: > 1. Create two configuration files, in my case I use a "default" embedded > configuration on the classpath, and a second configuration on disk for > overrides (this configuration uses monitorInterval=30). > 2. Configurator.initialize(null, classLoader, ImmutableList.of(defaultUri, > diskUri), null) > 3. On initial startup, the two configurations are merged perfectly, > everything works as expected. > 4. Modify the on disk (override) configuration while the application is > running, the failure is most apparent if I update a logger to reference an > appender only defined in the "default" configuration. Reconfiguration > executes but only using the file on disk, as though the first configuration > has disappeared. > This is a regression from 2.8.2, so I have rolled back to that version. > Unfortunately 2.8.2 is affected by LOG4J2-1912 and complains with misleading > warning messages so I've had to update the status logger to error level from > info. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (LOG4J2-2068) Can't set monitorInterval for composite XML configuration.
[
https://issues.apache.org/jira/browse/LOG4J2-2068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory resolved LOG4J2-2068.
--
Resolution: Fixed
Fix Version/s: 2.9.2
In Git master. Please verify and fix. Adding a unit test would be greatly
appreciated.
> Can't set monitorInterval for composite XML configuration.
> --
>
> Key: LOG4J2-2068
> URL: https://issues.apache.org/jira/browse/LOG4J2-2068
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.9.1
>Reporter: Robert Haycock
> Fix For: 2.9.2
>
> Attachments: patch_2068.diff
>
>
> When trying to combine a composite configuration with automatic reload, it
> fails to reload.
> When an {{XmlConfiguration}} is reloaded it calls
> {{XmlConfiguration.reconfigure()}} which sets the {{rootElement}} field, and
> everything is fine.
> When a {{CompositeConfiguration}} is reloaded, it doesn't call
> {{reconfigure()}} on the {{XmlConfigurations}}. This means when it tries to
> start the config {{XmlConfiguration.setup()}} is called and {{rootElement}}
> is null, resulting in an error message "No logging configuration".
> End result is the config isn't loaded and there's no more logging.
> To reproduce, it doesn't matter what is in the configurations. Just need at
> least 2 XML configs in the {{log4j.configurationFile}} property and the
> {{monitorInterval}} set.
> (Ps. my first ticket)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LOG4J2-2036) CompositeConfiguration with monitorInterval fails to reload full configuration
[ https://issues.apache.org/jira/browse/LOG4J2-2036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16200958#comment-16200958 ] ASF GitHub Bot commented on LOG4J2-2036: Github user garydgregory commented on the issue: https://github.com/apache/logging-log4j2/pull/115 By me to boot! > CompositeConfiguration with monitorInterval fails to reload full configuration > -- > > Key: LOG4J2-2036 > URL: https://issues.apache.org/jira/browse/LOG4J2-2036 > Project: Log4j 2 > Issue Type: Bug > Components: Configurators >Affects Versions: 2.9.0 > Environment: I have pushed a very simple repro here: > https://github.com/cakofony/log4j2-composite-config-repro >Reporter: Carter Douglas Kozak > > Steps to reproduce: > 1. Create two configuration files, in my case I use a "default" embedded > configuration on the classpath, and a second configuration on disk for > overrides (this configuration uses monitorInterval=30). > 2. Configurator.initialize(null, classLoader, ImmutableList.of(defaultUri, > diskUri), null) > 3. On initial startup, the two configurations are merged perfectly, > everything works as expected. > 4. Modify the on disk (override) configuration while the application is > running, the failure is most apparent if I update a logger to reference an > appender only defined in the "default" configuration. Reconfiguration > executes but only using the file on disk, as though the first configuration > has disappeared. > This is a regression from 2.8.2, so I have rolled back to that version. > Unfortunately 2.8.2 is affected by LOG4J2-1912 and complains with misleading > warning messages so I've had to update the status logger to error level from > info. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2036) CompositeConfiguration with monitorInterval fails to reload full configuration
[ https://issues.apache.org/jira/browse/LOG4J2-2036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16200847#comment-16200847 ] ASF GitHub Bot commented on LOG4J2-2036: Github user cakofony commented on the issue: https://github.com/apache/logging-log4j2/pull/115 @garydgregory issue appears to have been introduced here: 5b4f3db4f5e7b24862c147b790806bca0b2d1892 > CompositeConfiguration with monitorInterval fails to reload full configuration > -- > > Key: LOG4J2-2036 > URL: https://issues.apache.org/jira/browse/LOG4J2-2036 > Project: Log4j 2 > Issue Type: Bug > Components: Configurators >Affects Versions: 2.9.0 > Environment: I have pushed a very simple repro here: > https://github.com/cakofony/log4j2-composite-config-repro >Reporter: Carter Douglas Kozak > > Steps to reproduce: > 1. Create two configuration files, in my case I use a "default" embedded > configuration on the classpath, and a second configuration on disk for > overrides (this configuration uses monitorInterval=30). > 2. Configurator.initialize(null, classLoader, ImmutableList.of(defaultUri, > diskUri), null) > 3. On initial startup, the two configurations are merged perfectly, > everything works as expected. > 4. Modify the on disk (override) configuration while the application is > running, the failure is most apparent if I update a logger to reference an > appender only defined in the "default" configuration. Reconfiguration > executes but only using the file on disk, as though the first configuration > has disappeared. > This is a regression from 2.8.2, so I have rolled back to that version. > Unfortunately 2.8.2 is affected by LOG4J2-1912 and complains with misleading > warning messages so I've had to update the status logger to error level from > info. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2036) CompositeConfiguration with monitorInterval fails to reload full configuration
[ https://issues.apache.org/jira/browse/LOG4J2-2036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16200846#comment-16200846 ] ASF GitHub Bot commented on LOG4J2-2036: GitHub user cakofony opened a pull request: https://github.com/apache/logging-log4j2/pull/115 [LOG4J2-2036] CompositeConfiguration supports Reconfiguration Regression was introduced by the fix for LOG4J2-1912. You can merge this pull request into a Git repository by running: $ git pull https://github.com/cakofony/logging-log4j2 LOG4J2-2036 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/logging-log4j2/pull/115.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #115 commit 9bb0496cdef96a043c493e90d5df582b402a1afa Author: Carter Kozak <c4kof...@gmail.com> Date: 2017-10-11T19:43:50Z [LOG4J2-2036] CompositeConfiguration supports Reconfiguration Regression was introduced by the fix for LOG4J2-1912. > CompositeConfiguration with monitorInterval fails to reload full configuration > -- > > Key: LOG4J2-2036 > URL: https://issues.apache.org/jira/browse/LOG4J2-2036 > Project: Log4j 2 > Issue Type: Bug > Components: Configurators >Affects Versions: 2.9.0 > Environment: I have pushed a very simple repro here: > https://github.com/cakofony/log4j2-composite-config-repro >Reporter: Carter Douglas Kozak > > Steps to reproduce: > 1. Create two configuration files, in my case I use a "default" embedded > configuration on the classpath, and a second configuration on disk for > overrides (this configuration uses monitorInterval=30). > 2. Configurator.initialize(null, classLoader, ImmutableList.of(defaultUri, > diskUri), null) > 3. On initial startup, the two configurations are merged perfectly, > everything works as expected. > 4. Modify the on disk (override) configuration while the application is > running, the failure is most apparent if I update a logger to reference an > appender only defined in the "default" configuration. Reconfiguration > executes but only using the file on disk, as though the first configuration > has disappeared. > This is a regression from 2.8.2, so I have rolled back to that version. > Unfortunately 2.8.2 is affected by LOG4J2-1912 and complains with misleading > warning messages so I've had to update the status logger to error level from > info. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2068) Can't set monitorInterval for composite XML configuration.
[
https://issues.apache.org/jira/browse/LOG4J2-2068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16200540#comment-16200540
]
Gary Gregory commented on LOG4J2-2068:
--
Hi [~tedtrippin]:
Thank you for your patch! Can you please include a unit test that fails with
this change? Otherwise, another change could just inadvertently revert the fix.
Thank you,
Gary
> Can't set monitorInterval for composite XML configuration.
> --
>
> Key: LOG4J2-2068
> URL: https://issues.apache.org/jira/browse/LOG4J2-2068
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.9.1
>Reporter: Robert Haycock
> Attachments: patch_2068.diff
>
>
> When trying to combine a composite configuration with automatic reload, it
> fails to reload.
> When an {{XmlConfiguration}} is reloaded it calls
> {{XmlConfiguration.reconfigure()}} which sets the {{rootElement}} field, and
> everything is fine.
> When a {{CompositeConfiguration}} is reloaded, it doesn't call
> {{reconfigure()}} on the {{XmlConfigurations}}. This means when it tries to
> start the config {{XmlConfiguration.setup()}} is called and {{rootElement}}
> is null, resulting in an error message "No logging configuration".
> End result is the config isn't loaded and there's no more logging.
> To reproduce, it doesn't matter what is in the configurations. Just need at
> least 2 XML configs in the {{log4j.configurationFile}} property and the
> {{monitorInterval}} set.
> (Ps. my first ticket)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (LOG4J2-2070) Log4j1XmlLayout does not provide the entire stack trace, it is missing the caused by information
[ https://issues.apache.org/jira/browse/LOG4J2-2070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated LOG4J2-2070: - Fix Version/s: 2.9.2 > Log4j1XmlLayout does not provide the entire stack trace, it is missing the > caused by information > > > Key: LOG4J2-2070 > URL: https://issues.apache.org/jira/browse/LOG4J2-2070 > Project: Log4j 2 > Issue Type: Bug > Components: log4j 1.2 emulation >Affects Versions: 2.8.2 >Reporter: Doug Hughes > Fix For: 2.9.2 > > Attachments: patch.diff > > > Log4j1XmlLayout does not provide the entire stack trace, it is missing the > caused by information. > Attaching a patch that can correct this -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (LOG4J2-2070) Log4j1XmlLayout does not provide the entire stack trace, it is missing the caused by information
[ https://issues.apache.org/jira/browse/LOG4J2-2070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory resolved LOG4J2-2070. -- Resolution: Fixed In git master. Please verify and close. > Log4j1XmlLayout does not provide the entire stack trace, it is missing the > caused by information > > > Key: LOG4J2-2070 > URL: https://issues.apache.org/jira/browse/LOG4J2-2070 > Project: Log4j 2 > Issue Type: Bug > Components: log4j 1.2 emulation >Affects Versions: 2.8.2 >Reporter: Doug Hughes > Attachments: patch.diff > > > Log4j1XmlLayout does not provide the entire stack trace, it is missing the > caused by information. > Attaching a patch that can correct this -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2053) Exception java.nio.charset.UnsupportedCharsetException: cp65001 in 2.9.0
[
https://issues.apache.org/jira/browse/LOG4J2-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16200439#comment-16200439
]
ASF subversion and git services commented on LOG4J2-2053:
-
Commit 5f99a5d05254dc81a8c9c649e944f991f94529fa in logging-log4j2's branch
refs/heads/master from [~garydgregory]
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=5f99a5d ]
[LOG4J2-2053]
Exception java.nio.charset.UnsupportedCharsetException: cp65001 in
2.9.0. Add another entry.
> Exception java.nio.charset.UnsupportedCharsetException: cp65001 in 2.9.0
>
>
> Key: LOG4J2-2053
> URL: https://issues.apache.org/jira/browse/LOG4J2-2053
> Project: Log4j 2
> Issue Type: Bug
>Affects Versions: 2.9.0, 2.9.1
> Environment: Windows 10x64 1607 German
> Java JDK 1.8.0_144 (JAVA_TOOL_OPTIONS=-Dsun.jnu.encoding=UTF8
> -Dfile.encoding=UTF8 -Ds=0)
> Fitnesse 20161106
> Log4j 2.9.0
> Executing from command line, switching to chcp 65001
>Reporter: Frank Steudle
>Priority: Minor
> Attachments: Log4j-charsets.properties
>
>
> Today I updated my fitnesse project to use the 2.9.0 versions of log4-core
> and log4j-api. Now I am encountering the exception
> java.nio.charset.UnsupportedCharsetException: cp65001.
> However, my project is running well. Logging seems to work anyway.
> According to Issue 1888, there was a similar bug, which was fixed in 2.9.0:
> [https://issues.apache.org/jira/browse/LOG4J2-1888]. I commented it, but
> didn't get an answer until now.
> I am using ISO-8859-1 on my Eclipse computer to store the files. But the
> execution environment is plain UTF-8. Therefore I am using those parameters
> to run my fitnesse project:
> * -Dsun.jnu.encoding=UTF8: handed over as JAVA_TOOL_OPTIONS
> * -Dfile.encoding=UTF8: handed over as JAVA_TOOL_OPTIONS
> * chcp 65001: to switch the Windows console encoding to UTF8
> Here is the exception, which is thrown:
> {code:java}
> C:\Users\admin\Desktop\RabbitDevInstall\Testtool>java -jar
> RunRabbitRun-2.0-SNAPSHOT-jar-with-dependencies.jar start ./Resources
> Picked up JAVA_TOOL_OPTIONS: -Dsun.jnu.encoding=UTF8 -Dfile.encoding=UTF8
> -Ds=0
> Unable to get Charset 'sun.stdout.encoding', using default UTF-8
> java.nio.charset.UnsupportedCharsetException: cp65001
> at java.nio.charset.Charset.forName(Unknown Source)
> at
> org.apache.logging.log4j.util.PropertiesUtil.getCharsetProperty(PropertiesUtil.java:172)
> at
> org.apache.logging.log4j.core.appender.ConsoleAppender$Target.getCharset(ConsoleAppender.java:89)
> at
> org.apache.logging.log4j.core.appender.ConsoleAppender$Target$1.getDefaultCharset(ConsoleAppender.java:74)
> at
> org.apache.logging.log4j.core.appender.ConsoleAppender$Builder.build(ConsoleAppender.java:222)
> at
> org.apache.logging.log4j.core.appender.ConsoleAppender$Builder.build(ConsoleAppender.java:189)
> at
> org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.build(PluginBuilder.java:122)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.createPluginObject(AbstractConfiguration.java:958)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:898)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:890)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.doConfigure(AbstractConfiguration.java:513)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.initialize(AbstractConfiguration.java:237)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:249)
> at
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:545)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:617)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:634)
> at
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:229)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:152)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
> at org.apache.logging.log4j.LogManager.getContext(LogManager.java:194)
> at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:551)
> at de.d
[jira] [Comment Edited] (LOG4J2-2068) Can't set monitorInterval for composite XML configuration.
[
https://issues.apache.org/jira/browse/LOG4J2-2068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16200293#comment-16200293
]
Robert Haycock edited comment on LOG4J2-2068 at 10/11/17 2:52 PM:
--
This patch (attached) fixes the problem for me.
was (Author: tedtrippin):
This patch fixes the problem for me.
> Can't set monitorInterval for composite XML configuration.
> --
>
> Key: LOG4J2-2068
> URL: https://issues.apache.org/jira/browse/LOG4J2-2068
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.9.1
>Reporter: Robert Haycock
> Attachments: patch_2068.diff
>
>
> When trying to combine a composite configuration with automatic reload, it
> fails to reload.
> When an {{XmlConfiguration}} is reloaded it calls
> {{XmlConfiguration.reconfigure()}} which sets the {{rootElement}} field, and
> everything is fine.
> When a {{CompositeConfiguration}} is reloaded, it doesn't call
> {{reconfigure()}} on the {{XmlConfigurations}}. This means when it tries to
> start the config {{XmlConfiguration.setup()}} is called and {{rootElement}}
> is null, resulting in an error message "No logging configuration".
> End result is the config isn't loaded and there's no more logging.
> To reproduce, it doesn't matter what is in the configurations. Just need at
> least 2 XML configs in the {{log4j.configurationFile}} property and the
> {{monitorInterval}} set.
> (Ps. my first ticket)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (LOG4J2-2068) Can't set monitorInterval for composite XML configuration.
[
https://issues.apache.org/jira/browse/LOG4J2-2068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Haycock updated LOG4J2-2068:
---
Attachment: patch_2068.diff
This patch fixes the problem for me.
> Can't set monitorInterval for composite XML configuration.
> --
>
> Key: LOG4J2-2068
> URL: https://issues.apache.org/jira/browse/LOG4J2-2068
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.9.1
>Reporter: Robert Haycock
> Attachments: patch_2068.diff
>
>
> When trying to combine a composite configuration with automatic reload, it
> fails to reload.
> When an {{XmlConfiguration}} is reloaded it calls
> {{XmlConfiguration.reconfigure()}} which sets the {{rootElement}} field, and
> everything is fine.
> When a {{CompositeConfiguration}} is reloaded, it doesn't call
> {{reconfigure()}} on the {{XmlConfigurations}}. This means when it tries to
> start the config {{XmlConfiguration.setup()}} is called and {{rootElement}}
> is null, resulting in an error message "No logging configuration".
> End result is the config isn't loaded and there's no more logging.
> To reproduce, it doesn't matter what is in the configurations. Just need at
> least 2 XML configs in the {{log4j.configurationFile}} property and the
> {{monitorInterval}} set.
> (Ps. my first ticket)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LOG4J2-2061) RollingFileManager not removed when RollingFileAppender is stopped, using DirectWriteRolloverStrategy
[ https://issues.apache.org/jira/browse/LOG4J2-2061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16200248#comment-16200248 ] Matthew Hill commented on LOG4J2-2061: -- Hi [~garydgregory] Please see attached a sample junit that shows the issue. The comments within the junit show what is expected and what actually happens. Regards Matthew > RollingFileManager not removed when RollingFileAppender is stopped, using > DirectWriteRolloverStrategy > - > > Key: LOG4J2-2061 > URL: https://issues.apache.org/jira/browse/LOG4J2-2061 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.9.0 > Environment: * >Reporter: Matthew Hill >Priority: Blocker > Attachments: Log4jIssue.zip > > > When programmatically creating an instance of RollingFileAppender using > RollingFileAppender.newBuilder.(config options).build(), an instance of > RollingFileManager is created in AbstractManager.getManager(...), and this > instance is stored in the hashmap AbstractManager.MAP as well as on the > instance of RollingFileAppender in the super class > AbstractOutputStreamAppender. This manager is created and stored in the > AbstractManager.MAP with the name FILE_PATTERN (since we cannot create an > instance of RollingFileAppender with a file name using the > DirectWriteRolloverStrategy). However, the same manager is created with a > NAME of NULL since it is trying to use file name as the name of the manager, > but this parameter is not allowed using DirectWriteRolloverStrategy. > The problem here is that the RollingFileManager is created with a name of > FILE NAME (i.e., NULL when using DirectWriteRolloverStrategy) and added to > the hashmap with a key of FILE PATTERN, but when the rolling file appender is > stopped, it attempts to remove its manager from this MAP using > RollingFileManager.name, which equates to FILE NAME which is NULL. > Consider the following example: > * create a rolling file appender using the DirectWriteRolloverStrategy with a > file pattern of 'output.%i.log' > * a RollingFileManager is created with the name NULL, but put in > AbstractManager.MAP with the name 'output.%i.log' > * the rolling file appender is used to write a few line of log file > * the rolling file appender is stopped using RollingFileAppender.stop(..) > * the RollingFileManager is NOT removed from AbstractManager.MAP since it is > trying to remove FILE NAME but it is keyed on FILE PATTERN > * a NEW instance of rolling file appender is created using the > DirectWriteRolloverStrategy with the SAME file pattern of 'output.%i.log'. > * a new instance of RollingFileManager is NOT created, as it already exists > in the MAP, so the old instance is simply returned > * the instance of RollingFileManager for the new instance of > RollingFileAppender has a closed output stream, meaning that no logging is > possible. > In the above example you can see that if the old rolling file appender's > output stream is closed, and a new instance created with the same file > pattern, then the old manager will be used. I see no easy way of recreating > this output stream. > I found no documentation regarding why one cannot set the FILE NAME for a > RollingFileAppender using DirectWriteRolloverStrategy. Being able to > configure this may also solve the problem (unless it causes issues > elsewhere), but another possible fix to this issue is to create the > RollingFileManager with the name FILE PATTERN when using the > DirectWriteRolloverStrategy. This way we add to the MAP the instance of > RollingFileManager with the key FILE PATTERN, and we remove from the MAP > RollingFileManager.name which equals FILE PATTERN -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (LOG4J2-2061) RollingFileManager not removed when RollingFileAppender is stopped, using DirectWriteRolloverStrategy
[ https://issues.apache.org/jira/browse/LOG4J2-2061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthew Hill updated LOG4J2-2061: - Attachment: Log4jIssue.zip > RollingFileManager not removed when RollingFileAppender is stopped, using > DirectWriteRolloverStrategy > - > > Key: LOG4J2-2061 > URL: https://issues.apache.org/jira/browse/LOG4J2-2061 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.9.0 > Environment: * >Reporter: Matthew Hill >Priority: Blocker > Attachments: Log4jIssue.zip > > > When programmatically creating an instance of RollingFileAppender using > RollingFileAppender.newBuilder.(config options).build(), an instance of > RollingFileManager is created in AbstractManager.getManager(...), and this > instance is stored in the hashmap AbstractManager.MAP as well as on the > instance of RollingFileAppender in the super class > AbstractOutputStreamAppender. This manager is created and stored in the > AbstractManager.MAP with the name FILE_PATTERN (since we cannot create an > instance of RollingFileAppender with a file name using the > DirectWriteRolloverStrategy). However, the same manager is created with a > NAME of NULL since it is trying to use file name as the name of the manager, > but this parameter is not allowed using DirectWriteRolloverStrategy. > The problem here is that the RollingFileManager is created with a name of > FILE NAME (i.e., NULL when using DirectWriteRolloverStrategy) and added to > the hashmap with a key of FILE PATTERN, but when the rolling file appender is > stopped, it attempts to remove its manager from this MAP using > RollingFileManager.name, which equates to FILE NAME which is NULL. > Consider the following example: > * create a rolling file appender using the DirectWriteRolloverStrategy with a > file pattern of 'output.%i.log' > * a RollingFileManager is created with the name NULL, but put in > AbstractManager.MAP with the name 'output.%i.log' > * the rolling file appender is used to write a few line of log file > * the rolling file appender is stopped using RollingFileAppender.stop(..) > * the RollingFileManager is NOT removed from AbstractManager.MAP since it is > trying to remove FILE NAME but it is keyed on FILE PATTERN > * a NEW instance of rolling file appender is created using the > DirectWriteRolloverStrategy with the SAME file pattern of 'output.%i.log'. > * a new instance of RollingFileManager is NOT created, as it already exists > in the MAP, so the old instance is simply returned > * the instance of RollingFileManager for the new instance of > RollingFileAppender has a closed output stream, meaning that no logging is > possible. > In the above example you can see that if the old rolling file appender's > output stream is closed, and a new instance created with the same file > pattern, then the old manager will be used. I see no easy way of recreating > this output stream. > I found no documentation regarding why one cannot set the FILE NAME for a > RollingFileAppender using DirectWriteRolloverStrategy. Being able to > configure this may also solve the problem (unless it causes issues > elsewhere), but another possible fix to this issue is to create the > RollingFileManager with the name FILE PATTERN when using the > DirectWriteRolloverStrategy. This way we add to the MAP the instance of > RollingFileManager with the key FILE PATTERN, and we remove from the MAP > RollingFileManager.name which equals FILE PATTERN -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (LOG4J2-2070) Log4j1XmlLayout does not provide the entire stack trace, it is missing the caused by information
[ https://issues.apache.org/jira/browse/LOG4J2-2070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Doug Hughes updated LOG4J2-2070: Attachment: patch.diff > Log4j1XmlLayout does not provide the entire stack trace, it is missing the > caused by information > > > Key: LOG4J2-2070 > URL: https://issues.apache.org/jira/browse/LOG4J2-2070 > Project: Log4j 2 > Issue Type: Bug > Components: log4j 1.2 emulation >Affects Versions: 2.8.2 >Reporter: Doug Hughes > Attachments: patch.diff > > > Log4j1XmlLayout does not provide the entire stack trace, it is missing the > caused by information. > Attaching a patch that can correct this -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (LOG4J2-2070) Log4j1XmlLayout does not provide the entire stack trace, it is missing the caused by information
Doug Hughes created LOG4J2-2070: --- Summary: Log4j1XmlLayout does not provide the entire stack trace, it is missing the caused by information Key: LOG4J2-2070 URL: https://issues.apache.org/jira/browse/LOG4J2-2070 Project: Log4j 2 Issue Type: Bug Components: log4j 1.2 emulation Affects Versions: 2.8.2 Reporter: Doug Hughes Log4j1XmlLayout does not provide the entire stack trace, it is missing the caused by information. Attaching a patch that can correct this -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (LOG4J2-2069) --multi-release option not set for the multi-release jar.
[
https://issues.apache.org/jira/browse/LOG4J2-2069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Naman Nigam updated LOG4J2-2069:
Summary: --multi-release option not set for the multi-release jar. (was:
--multi-release option not set for the MultiRelease jar.)
> --multi-release option not set for the multi-release jar.
> -
>
> Key: LOG4J2-2069
> URL: https://issues.apache.org/jira/browse/LOG4J2-2069
> Project: Log4j 2
> Issue Type: Bug
> Components: API
>Reporter: Naman Nigam
>
> Executing Jdeps on the `log4j-api-2.9.1.jar` results into an error:-
> {quote} Error: log4j-api-2.9.1.jar is a multi-release jar file but
> --multi-release option is not set
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (LOG4J2-2069) --multi-release option not set for the MultiRelease jar.
Naman Nigam created LOG4J2-2069:
---
Summary: --multi-release option not set for the MultiRelease jar.
Key: LOG4J2-2069
URL: https://issues.apache.org/jira/browse/LOG4J2-2069
Project: Log4j 2
Issue Type: Bug
Components: API
Reporter: Naman Nigam
Executing Jdeps on the `log4j-api-2.9.1.jar` results into an error:-
{quote} Error: log4j-api-2.9.1.jar is a multi-release jar file but
--multi-release option is not set
{quote}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LOG4J2-2053) Exception java.nio.charset.UnsupportedCharsetException: cp65001 in 2.9.0
[
https://issues.apache.org/jira/browse/LOG4J2-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16199873#comment-16199873
]
Frank Steudle commented on LOG4J2-2053:
---
Thank you for your endeavours! My runtime is Oracle Java 8u144 on Windows 7
Professional 64 Bit. I haven't executed the test before, because currently I
don't have the time to accomplish this task. I am new to GitHub and to
contribute to Apache projects.
I mentioned your changes to the file. In my opinion we could leave it like
this.
Would it be a good idea, if we submit a feature to the ICU project? Then they
are able to include the missing codepages in their alternatives sections.
> Exception java.nio.charset.UnsupportedCharsetException: cp65001 in 2.9.0
>
>
> Key: LOG4J2-2053
> URL: https://issues.apache.org/jira/browse/LOG4J2-2053
> Project: Log4j 2
> Issue Type: Bug
>Affects Versions: 2.9.0, 2.9.1
> Environment: Windows 10x64 1607 German
> Java JDK 1.8.0_144 (JAVA_TOOL_OPTIONS=-Dsun.jnu.encoding=UTF8
> -Dfile.encoding=UTF8 -Ds=0)
> Fitnesse 20161106
> Log4j 2.9.0
> Executing from command line, switching to chcp 65001
>Reporter: Frank Steudle
>Priority: Minor
> Attachments: Log4j-charsets.properties
>
>
> Today I updated my fitnesse project to use the 2.9.0 versions of log4-core
> and log4j-api. Now I am encountering the exception
> java.nio.charset.UnsupportedCharsetException: cp65001.
> However, my project is running well. Logging seems to work anyway.
> According to Issue 1888, there was a similar bug, which was fixed in 2.9.0:
> [https://issues.apache.org/jira/browse/LOG4J2-1888]. I commented it, but
> didn't get an answer until now.
> I am using ISO-8859-1 on my Eclipse computer to store the files. But the
> execution environment is plain UTF-8. Therefore I am using those parameters
> to run my fitnesse project:
> * -Dsun.jnu.encoding=UTF8: handed over as JAVA_TOOL_OPTIONS
> * -Dfile.encoding=UTF8: handed over as JAVA_TOOL_OPTIONS
> * chcp 65001: to switch the Windows console encoding to UTF8
> Here is the exception, which is thrown:
> {code:java}
> C:\Users\admin\Desktop\RabbitDevInstall\Testtool>java -jar
> RunRabbitRun-2.0-SNAPSHOT-jar-with-dependencies.jar start ./Resources
> Picked up JAVA_TOOL_OPTIONS: -Dsun.jnu.encoding=UTF8 -Dfile.encoding=UTF8
> -Ds=0
> Unable to get Charset 'sun.stdout.encoding', using default UTF-8
> java.nio.charset.UnsupportedCharsetException: cp65001
> at java.nio.charset.Charset.forName(Unknown Source)
> at
> org.apache.logging.log4j.util.PropertiesUtil.getCharsetProperty(PropertiesUtil.java:172)
> at
> org.apache.logging.log4j.core.appender.ConsoleAppender$Target.getCharset(ConsoleAppender.java:89)
> at
> org.apache.logging.log4j.core.appender.ConsoleAppender$Target$1.getDefaultCharset(ConsoleAppender.java:74)
> at
> org.apache.logging.log4j.core.appender.ConsoleAppender$Builder.build(ConsoleAppender.java:222)
> at
> org.apache.logging.log4j.core.appender.ConsoleAppender$Builder.build(ConsoleAppender.java:189)
> at
> org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.build(PluginBuilder.java:122)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.createPluginObject(AbstractConfiguration.java:958)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:898)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:890)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.doConfigure(AbstractConfiguration.java:513)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.initialize(AbstractConfiguration.java:237)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:249)
> at
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:545)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:617)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:634)
> at
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:229)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:152)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
> at org.a
[jira] [Commented] (LOG4J2-2060) AbstactDatabase appender issue with AsyncLogger
[
https://issues.apache.org/jira/browse/LOG4J2-2060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16199870#comment-16199870
]
Tolga Kavukcu commented on LOG4J2-2060:
---
Sure i can provide the unit test case.
> AbstactDatabase appender issue with AsyncLogger
> ---
>
> Key: LOG4J2-2060
> URL: https://issues.apache.org/jira/browse/LOG4J2-2060
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.8.1, 2.8.2
>Reporter: Tolga Kavukcu
>Assignee: Remko Popma
> Fix For: 2.9.2
>
>
> Log4j2 AsycLogger Implementation with a database appender has an issue.
> As i investigated the async logger mechanism works like that.
> Messages are put into DistruptorRingBuffer
> Than
> *RingBufferLogEventHandler*'s *onEvent* mehtod is called and message is
> passed to appender asyncronously.
> In *AbstractDatabaseAppender* case
> The messages also put into an *ArrayList* to make batches for bulk insert to
> table.
> {code:java}
> @Override
> public final void append(final LogEvent event) {
> this.readLock.lock();
> try {
> this.getManager().write(event);
> } catch (final LoggingException e) {
> LOGGER.error("Unable to write to database [{}] for appender [{}].",
> this.getManager().getName(),
> this.getName(), e);
> throw e;
> } catch (final Exception e) {
> LOGGER.error("Unable to write to database [{}] for appender [{}].",
> this.getManager().getName(),
> this.getName(), e);
> throw new AppenderLoggingException("Unable to write to database in
> appender: " + e.getMessage(), e);
> } finally {
> this.readLock.unlock();
> }
> }
> {code}
> Than *Abstract Database Manager* puts *LogEvent* into *ArrayList*
> {code:java}
> public final synchronized void write(final LogEvent event) {
> if (this.bufferSize > 0) {
> this.buffer.add(event);
> if (this.buffer.size() >= this.bufferSize || event.isEndOfBatch()) {
> this.flush();
> }
> } else {
> this.connectAndStart();
> try {
> this.writeInternal(event);
> } finally {
> this.commitAndClose();
> }
> }
> }
> {code}
> After that correspoding *LogEvent* object can be re-used in the
> *DistruptorRingBuffer* mechanism.
> When a delay happens in the database the *LogEvent* objects are overriden
> with same referance which causes inconsitency while preparing batches.
> I believe this points to a bug or design problem.
> I would like to contribute solution if anyone can guide where to start what
> might be the possible design.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LOG4J2-2061) RollingFileManager not removed when RollingFileAppender is stopped, using DirectWriteRolloverStrategy
[ https://issues.apache.org/jira/browse/LOG4J2-2061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16199534#comment-16199534 ] Gary Gregory commented on LOG4J2-2061: -- Hi [~matthewhill], Are you able to provide a unit test that reproduces the problem? This ticket is more likely to get some attention with some test code attached ;-) Thank you! Gary > RollingFileManager not removed when RollingFileAppender is stopped, using > DirectWriteRolloverStrategy > - > > Key: LOG4J2-2061 > URL: https://issues.apache.org/jira/browse/LOG4J2-2061 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.9.0 > Environment: * >Reporter: Matthew Hill >Priority: Blocker > > When programmatically creating an instance of RollingFileAppender using > RollingFileAppender.newBuilder.(config options).build(), an instance of > RollingFileManager is created in AbstractManager.getManager(...), and this > instance is stored in the hashmap AbstractManager.MAP as well as on the > instance of RollingFileAppender in the super class > AbstractOutputStreamAppender. This manager is created and stored in the > AbstractManager.MAP with the name FILE_PATTERN (since we cannot create an > instance of RollingFileAppender with a file name using the > DirectWriteRolloverStrategy). However, the same manager is created with a > NAME of NULL since it is trying to use file name as the name of the manager, > but this parameter is not allowed using DirectWriteRolloverStrategy. > The problem here is that the RollingFileManager is created with a name of > FILE NAME (i.e., NULL when using DirectWriteRolloverStrategy) and added to > the hashmap with a key of FILE PATTERN, but when the rolling file appender is > stopped, it attempts to remove its manager from this MAP using > RollingFileManager.name, which equates to FILE NAME which is NULL. > Consider the following example: > * create a rolling file appender using the DirectWriteRolloverStrategy with a > file pattern of 'output.%i.log' > * a RollingFileManager is created with the name NULL, but put in > AbstractManager.MAP with the name 'output.%i.log' > * the rolling file appender is used to write a few line of log file > * the rolling file appender is stopped using RollingFileAppender.stop(..) > * the RollingFileManager is NOT removed from AbstractManager.MAP since it is > trying to remove FILE NAME but it is keyed on FILE PATTERN > * a NEW instance of rolling file appender is created using the > DirectWriteRolloverStrategy with the SAME file pattern of 'output.%i.log'. > * a new instance of RollingFileManager is NOT created, as it already exists > in the MAP, so the old instance is simply returned > * the instance of RollingFileManager for the new instance of > RollingFileAppender has a closed output stream, meaning that no logging is > possible. > In the above example you can see that if the old rolling file appender's > output stream is closed, and a new instance created with the same file > pattern, then the old manager will be used. I see no easy way of recreating > this output stream. > I found no documentation regarding why one cannot set the FILE NAME for a > RollingFileAppender using DirectWriteRolloverStrategy. Being able to > configure this may also solve the problem (unless it causes issues > elsewhere), but another possible fix to this issue is to create the > RollingFileManager with the name FILE PATTERN when using the > DirectWriteRolloverStrategy. This way we add to the MAP the instance of > RollingFileManager with the key FILE PATTERN, and we remove from the MAP > RollingFileManager.name which equals FILE PATTERN -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (LOG4J2-2067) Using PatternSelectors breaks header printing in PatternLayout
[
https://issues.apache.org/jira/browse/LOG4J2-2067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16199531#comment-16199531
]
Gary Gregory edited comment on LOG4J2-2067 at 10/10/17 11:03 PM:
-
Would you be able to provide a unit test we can run that breaks without this
patch?
was (Author: garydgregory):
Would you be able to provide a unit test we can run that breaks with this patch?
> Using PatternSelectors breaks header printing in PatternLayout
> --
>
> Key: LOG4J2-2067
> URL: https://issues.apache.org/jira/browse/LOG4J2-2067
> Project: Log4j 2
> Issue Type: Bug
> Components: Layouts, Pattern Converters
>Affects Versions: 2.8.2, 2.9.0
>Reporter: Paul Burrowes
>
> Using a config of
> {code}
>
>
>
>
>
>
> filePattern="foo.log.%i">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> the header is expected to be formatted according to the pattern configured
> but instead the output is
> {code}
> 2017-10-09 14:25:12.072+1300
> 2017-10-09 14:25:12.143+1300 using interpolation and a throwable
> java.lang.NullPointerException
> java.lang.NullPointerException: null
> at leliel.Main.main(Main.java:51) [Log4j2-testing/:?]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ~[?:1.7.0_79]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> ~[?:1.7.0_79]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[?:1.7.0_79]
> at java.lang.reflect.Method.invoke(Method.java:606) ~[?:1.7.0_79]
> at
> com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> [idea_rt.jar:?]
> 2017-10-09 14:25:12.151+1300 throwable only
> {code}
> The fix appears to simply be to not provide the PatternSelector to the header
> and footer Serializer builders.
> {code}
> diff --git
> a/log4j-core/src/main/java/org/apache/logging/log4j/core/layout/PatternLayout.java
>
> b/log4j-core/src/main/java/org/apache/logging/log4j/core/layout/PatternLayout.java
> index e4440eb9b..39042081f 100644
> ---
> a/log4j-core/src/main/java/org/apache/logging/log4j/core/layout/PatternLayout.java
> +++
> b/log4j-core/src/main/java/org/apache/logging/log4j/core/layout/PatternLayout.java
> @@ -108,7 +108,7 @@ public final class PatternLayout extends
> AbstractStringLayout {
> newSerializerBuilder()
> .setConfiguration(config)
> .setReplace(replace)
> -.setPatternSelector(patternSelector)
> +.setPatternSelector(null)
> .setAlwaysWriteExceptions(alwaysWriteExceptions)
> .setDisableAnsi(disableAnsi)
> .setNoConsoleNoAnsi(noConsoleNoAnsi)
> @@ -117,7 +117,7 @@ public final class PatternLayout extends
> AbstractStringLayout {
> newSerializerBuilder()
> .setConfiguration(config)
> .setReplace(replace)
> -.setPatternSelector(patternSelector)
> + .setPatternSelector(null)
> .setAlwaysWriteExceptions(alwaysWriteExceptions)
> .setDisableAnsi(disableAnsi)
> .setNoConsoleNoAnsi(noConsoleNoAnsi)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LOG4J2-2053) Exception java.nio.charset.UnsupportedCharsetException: cp65001 in 2.9.0
[
https://issues.apache.org/jira/browse/LOG4J2-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16199526#comment-16199526
]
Gary Gregory commented on LOG4J2-2053:
--
Please run the test org.apache.logging.log4j.util.Log4jCharsetsPropertiesTest
before submitting changes. I had to remove many entries that are already
mapped. Or, did the test pass for you? If yes, what is you Java vendor and
version?
I tested with Oracle Java 1.7.0_80, Oracle Java 8 (latest), Oracle Java 9, IBM
Java 8.
> Exception java.nio.charset.UnsupportedCharsetException: cp65001 in 2.9.0
>
>
> Key: LOG4J2-2053
> URL: https://issues.apache.org/jira/browse/LOG4J2-2053
> Project: Log4j 2
> Issue Type: Bug
>Affects Versions: 2.9.0, 2.9.1
> Environment: Windows 10x64 1607 German
> Java JDK 1.8.0_144 (JAVA_TOOL_OPTIONS=-Dsun.jnu.encoding=UTF8
> -Dfile.encoding=UTF8 -Ds=0)
> Fitnesse 20161106
> Log4j 2.9.0
> Executing from command line, switching to chcp 65001
>Reporter: Frank Steudle
>Priority: Minor
> Attachments: Log4j-charsets.properties
>
>
> Today I updated my fitnesse project to use the 2.9.0 versions of log4-core
> and log4j-api. Now I am encountering the exception
> java.nio.charset.UnsupportedCharsetException: cp65001.
> However, my project is running well. Logging seems to work anyway.
> According to Issue 1888, there was a similar bug, which was fixed in 2.9.0:
> [https://issues.apache.org/jira/browse/LOG4J2-1888]. I commented it, but
> didn't get an answer until now.
> I am using ISO-8859-1 on my Eclipse computer to store the files. But the
> execution environment is plain UTF-8. Therefore I am using those parameters
> to run my fitnesse project:
> * -Dsun.jnu.encoding=UTF8: handed over as JAVA_TOOL_OPTIONS
> * -Dfile.encoding=UTF8: handed over as JAVA_TOOL_OPTIONS
> * chcp 65001: to switch the Windows console encoding to UTF8
> Here is the exception, which is thrown:
> {code:java}
> C:\Users\admin\Desktop\RabbitDevInstall\Testtool>java -jar
> RunRabbitRun-2.0-SNAPSHOT-jar-with-dependencies.jar start ./Resources
> Picked up JAVA_TOOL_OPTIONS: -Dsun.jnu.encoding=UTF8 -Dfile.encoding=UTF8
> -Ds=0
> Unable to get Charset 'sun.stdout.encoding', using default UTF-8
> java.nio.charset.UnsupportedCharsetException: cp65001
> at java.nio.charset.Charset.forName(Unknown Source)
> at
> org.apache.logging.log4j.util.PropertiesUtil.getCharsetProperty(PropertiesUtil.java:172)
> at
> org.apache.logging.log4j.core.appender.ConsoleAppender$Target.getCharset(ConsoleAppender.java:89)
> at
> org.apache.logging.log4j.core.appender.ConsoleAppender$Target$1.getDefaultCharset(ConsoleAppender.java:74)
> at
> org.apache.logging.log4j.core.appender.ConsoleAppender$Builder.build(ConsoleAppender.java:222)
> at
> org.apache.logging.log4j.core.appender.ConsoleAppender$Builder.build(ConsoleAppender.java:189)
> at
> org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.build(PluginBuilder.java:122)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.createPluginObject(AbstractConfiguration.java:958)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:898)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:890)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.doConfigure(AbstractConfiguration.java:513)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.initialize(AbstractConfiguration.java:237)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:249)
> at
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:545)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:617)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:634)
> at
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:229)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:152)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
> at org.apache.logging.log4j.LogManager.getContext(LogManager.java:194)
> at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:551)
> at de.duerr.fitnesse
[jira] [Commented] (LOG4J2-2053) Exception java.nio.charset.UnsupportedCharsetException: cp65001 in 2.9.0
[
https://issues.apache.org/jira/browse/LOG4J2-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16199522#comment-16199522
]
ASF subversion and git services commented on LOG4J2-2053:
-
Commit 60636bafbb178b2b5e30b54dd7f1575426281583 in logging-log4j2's branch
refs/heads/master from [~garydgregory]
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=60636ba ]
[LOG4J2-2053]
Exception java.nio.charset.UnsupportedCharsetException: cp65001 in 2.9.0
> Exception java.nio.charset.UnsupportedCharsetException: cp65001 in 2.9.0
>
>
> Key: LOG4J2-2053
> URL: https://issues.apache.org/jira/browse/LOG4J2-2053
> Project: Log4j 2
> Issue Type: Bug
>Affects Versions: 2.9.0, 2.9.1
> Environment: Windows 10x64 1607 German
> Java JDK 1.8.0_144 (JAVA_TOOL_OPTIONS=-Dsun.jnu.encoding=UTF8
> -Dfile.encoding=UTF8 -Ds=0)
> Fitnesse 20161106
> Log4j 2.9.0
> Executing from command line, switching to chcp 65001
>Reporter: Frank Steudle
>Priority: Minor
> Attachments: Log4j-charsets.properties
>
>
> Today I updated my fitnesse project to use the 2.9.0 versions of log4-core
> and log4j-api. Now I am encountering the exception
> java.nio.charset.UnsupportedCharsetException: cp65001.
> However, my project is running well. Logging seems to work anyway.
> According to Issue 1888, there was a similar bug, which was fixed in 2.9.0:
> [https://issues.apache.org/jira/browse/LOG4J2-1888]. I commented it, but
> didn't get an answer until now.
> I am using ISO-8859-1 on my Eclipse computer to store the files. But the
> execution environment is plain UTF-8. Therefore I am using those parameters
> to run my fitnesse project:
> * -Dsun.jnu.encoding=UTF8: handed over as JAVA_TOOL_OPTIONS
> * -Dfile.encoding=UTF8: handed over as JAVA_TOOL_OPTIONS
> * chcp 65001: to switch the Windows console encoding to UTF8
> Here is the exception, which is thrown:
> {code:java}
> C:\Users\admin\Desktop\RabbitDevInstall\Testtool>java -jar
> RunRabbitRun-2.0-SNAPSHOT-jar-with-dependencies.jar start ./Resources
> Picked up JAVA_TOOL_OPTIONS: -Dsun.jnu.encoding=UTF8 -Dfile.encoding=UTF8
> -Ds=0
> Unable to get Charset 'sun.stdout.encoding', using default UTF-8
> java.nio.charset.UnsupportedCharsetException: cp65001
> at java.nio.charset.Charset.forName(Unknown Source)
> at
> org.apache.logging.log4j.util.PropertiesUtil.getCharsetProperty(PropertiesUtil.java:172)
> at
> org.apache.logging.log4j.core.appender.ConsoleAppender$Target.getCharset(ConsoleAppender.java:89)
> at
> org.apache.logging.log4j.core.appender.ConsoleAppender$Target$1.getDefaultCharset(ConsoleAppender.java:74)
> at
> org.apache.logging.log4j.core.appender.ConsoleAppender$Builder.build(ConsoleAppender.java:222)
> at
> org.apache.logging.log4j.core.appender.ConsoleAppender$Builder.build(ConsoleAppender.java:189)
> at
> org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.build(PluginBuilder.java:122)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.createPluginObject(AbstractConfiguration.java:958)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:898)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:890)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.doConfigure(AbstractConfiguration.java:513)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.initialize(AbstractConfiguration.java:237)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:249)
> at
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:545)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:617)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:634)
> at
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:229)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:152)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
> at org.apache.logging.log4j.LogManager.getContext(LogManager.java:194)
> at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:551)
> at de.duerr.fitnesse.RunRabbitRun.(
[jira] [Updated] (LOG4J2-1216) Nested pattern layout options broken
[
https://issues.apache.org/jira/browse/LOG4J2-1216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated LOG4J2-1216:
-
Affects Version/s: 2.9.1
> Nested pattern layout options broken
>
>
> Key: LOG4J2-1216
> URL: https://issues.apache.org/jira/browse/LOG4J2-1216
> Project: Log4j 2
> Issue Type: Bug
> Components: Pattern Converters
>Affects Versions: 2.4.1, 2.9.1
>Reporter: Thies Wellpott
> Labels: easyfix
> Fix For: 2.9.2
>
>
> Parsing the "deeply" nested PatternLayout
> {code}
> %maxLen{[XXX, ${hostName}, ${web:contextPath}] %p: %c{1} - %m%notEmpty{
> =>%ex{short}}}{160}
> {code}
> (with %maxLen being a custom Converter)
> results in wrong parsing.
> Patternparser.extractOptions() gets the nesting wrong.
> Solution:
> {code}
> private static int extractOptions(final String pattern, final int start,
> final List options) {
> int i = start;
> while (i < pattern.length() && pattern.charAt(i) == '{') {
> i++; // skip opening "{"
> final int begin = i; // position of first real char
> int depth = 1;// already inside one level
> while (depth > 0 && i < pattern.length()) {
> char c = pattern.charAt(i);
> if (c == '{') {
> depth++;
> } else if (c == '}') {
> depth--;
> // TODO(?) maybe escaping of { and } with \ or %
> }
> i++;
> } // while
> if (depth > 0) { // option not closed, continue with pattern
> on opening "{"
> return begin-1;
> }
> options.add(pattern.substring(begin, i-1));
> } // while
> return i;
> }
> {code}
> This should also be faster than the current implementation because the
> pattern ist only walked once, not multiple times with indexOf().
> (LOG4J2-107 is a similar but old bug)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (LOG4J2-1216) Nested pattern layout options broken
[
https://issues.apache.org/jira/browse/LOG4J2-1216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory resolved LOG4J2-1216.
--
Resolution: Fixed
Fix Version/s: 2.9.2
Setting to Resolved: Fixed in git master.
Please verify and close.
> Nested pattern layout options broken
>
>
> Key: LOG4J2-1216
> URL: https://issues.apache.org/jira/browse/LOG4J2-1216
> Project: Log4j 2
> Issue Type: Bug
> Components: Pattern Converters
>Affects Versions: 2.4.1, 2.9.1
>Reporter: Thies Wellpott
> Labels: easyfix
> Fix For: 2.9.2
>
>
> Parsing the "deeply" nested PatternLayout
> {code}
> %maxLen{[XXX, ${hostName}, ${web:contextPath}] %p: %c{1} - %m%notEmpty{
> =>%ex{short}}}{160}
> {code}
> (with %maxLen being a custom Converter)
> results in wrong parsing.
> Patternparser.extractOptions() gets the nesting wrong.
> Solution:
> {code}
> private static int extractOptions(final String pattern, final int start,
> final List options) {
> int i = start;
> while (i < pattern.length() && pattern.charAt(i) == '{') {
> i++; // skip opening "{"
> final int begin = i; // position of first real char
> int depth = 1;// already inside one level
> while (depth > 0 && i < pattern.length()) {
> char c = pattern.charAt(i);
> if (c == '{') {
> depth++;
> } else if (c == '}') {
> depth--;
> // TODO(?) maybe escaping of { and } with \ or %
> }
> i++;
> } // while
> if (depth > 0) { // option not closed, continue with pattern
> on opening "{"
> return begin-1;
> }
> options.add(pattern.substring(begin, i-1));
> } // while
> return i;
> }
> {code}
> This should also be faster than the current implementation because the
> pattern ist only walked once, not multiple times with indexOf().
> (LOG4J2-107 is a similar but old bug)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LOG4J2-1216) Nested pattern layout options broken
[
https://issues.apache.org/jira/browse/LOG4J2-1216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16199473#comment-16199473
]
ASF subversion and git services commented on LOG4J2-1216:
-
Commit 0049d85a4c789974ea6354d390ba65173db8937a in logging-log4j2's branch
refs/heads/master from [~githubbot]
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=0049d85 ]
[LOG4J2-1216] Nested pattern layout options broken. Apply slightly
tweaked patch for formatting.
> Nested pattern layout options broken
>
>
> Key: LOG4J2-1216
> URL: https://issues.apache.org/jira/browse/LOG4J2-1216
> Project: Log4j 2
> Issue Type: Bug
> Components: Pattern Converters
>Affects Versions: 2.4.1
>Reporter: Thies Wellpott
> Labels: easyfix
>
> Parsing the "deeply" nested PatternLayout
> {code}
> %maxLen{[XXX, ${hostName}, ${web:contextPath}] %p: %c{1} - %m%notEmpty{
> =>%ex{short}}}{160}
> {code}
> (with %maxLen being a custom Converter)
> results in wrong parsing.
> Patternparser.extractOptions() gets the nesting wrong.
> Solution:
> {code}
> private static int extractOptions(final String pattern, final int start,
> final List options) {
> int i = start;
> while (i < pattern.length() && pattern.charAt(i) == '{') {
> i++; // skip opening "{"
> final int begin = i; // position of first real char
> int depth = 1;// already inside one level
> while (depth > 0 && i < pattern.length()) {
> char c = pattern.charAt(i);
> if (c == '{') {
> depth++;
> } else if (c == '}') {
> depth--;
> // TODO(?) maybe escaping of { and } with \ or %
> }
> i++;
> } // while
> if (depth > 0) { // option not closed, continue with pattern
> on opening "{"
> return begin-1;
> }
> options.add(pattern.substring(begin, i-1));
> } // while
> return i;
> }
> {code}
> This should also be faster than the current implementation because the
> pattern ist only walked once, not multiple times with indexOf().
> (LOG4J2-107 is a similar but old bug)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (LOG4J2-2056) Modularize Log4j as automatic modules
[ https://issues.apache.org/jira/browse/LOG4J2-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated LOG4J2-2056: - Description: To fully support Java 9 all Log4j jars must (at least) be packaged as automatic modules. We should, as much as possible, follow the recommendations at http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html. Given that the module names would be: ||Artifact ID ||Module name|| |log4j-api|org.apache.logging.log4j| |log4j-core|org.apache.logging.log4j.core| |log4j-1.2-api|org.apache.log4j| |log4j-appserver|org.apache.logging.log4j.appserver| |log4j-flume-ng|org.apache.logging.log4j.flume| |log4j-iostreams|org.apache.logging.log4j.iostreams| |log4j-jcl|org.apache.logging.log4j.jcl| |log4j-jmx-gui|org.apache.logging.log4j.jmx.gui| |log4j-jul|org.apache.logging.log4j.jul| |log4j-nosql|org.apache.logging.log4j.nosql| |log4j-osgi|org.apache.logging.log4j.osgi| |log4j-sl4j-impl|org.apache.logging.log4j.slf4j.impl*| |log4j-to-slf4j|org.apache.logging.log4j.to.slf4j| |log4j-taglib|org.apache.logging.log4j.taglib| |log4j-web|org.apache.logging.log4j.web| # log4j-liquibase uses a package name outside the org.apache.logging.log4j namespace so is not modularized. # log4j-slf4j-impl cannot currently be modularized until the binding is modified. It cannot have classes in the org.slf4j namespace. # log4j-slf4j-impl and log4j-to-slf4j both use the same package name - org.apache.logging.log4j.slf4j. This will remain the same as it will prevent them both from being loaded at the same time. was: To fully support Java 9 all Log4j jars must (at least) be packaged as automatic modules. We should, as much as possible, follow the recommendations at http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html. Given that the module names would be: ||Jar name||Module name|| |log4j-api|org.apache.logging.log4j| |log4j-core|org.apache.logging.log4j.core| |log4j-1.2-api|org.apache.log4j| |log4j-appserver|org.apache.logging.log4j.appserver| |log4j-flume-ng|org.apache.logging.log4j.flume| |log4j-iostreams|org.apache.logging.log4j.iostreams| |log4j-jcl|org.apache.logging.log4j.jcl| |log4j-jmx-gui|org.apache.logging.log4j.jmx.gui| |log4j-jul|org.apache.logging.log4j.jul| |log4j-nosql|org.apache.logging.log4j.nosql| |log4j-osgi|org.apache.logging.log4j.osgi| |log4j-sl4j-impl|org.apache.logging.log4j.slf4j.impl*| |log4j-to-slf4j|org.apache.logging.log4j.to.slf4j| |log4j-taglib|org.apache.logging.log4j.taglib| |log4j-web|org.apache.logging.log4j.web| # log4j-liquibase uses a package name outside the org.apache.logging.log4j namespace so is not modularized. # log4j-slf4j-impl cannot currently be modularized until the binding is modified. It cannot have classes in the org.slf4j namespace. # log4j-slf4j-impl and log4j-to-slf4j both use the same package name - org.apache.logging.log4j.slf4j. This will remain the same as it will prevent them both from being loaded at the same time. > Modularize Log4j as automatic modules > - > > Key: LOG4J2-2056 > URL: https://issues.apache.org/jira/browse/LOG4J2-2056 > Project: Log4j 2 > Issue Type: New Feature >Affects Versions: 2.9.1 >Reporter: Ralph Goers >Assignee: Ralph Goers > > To fully support Java 9 all Log4j jars must (at least) be packaged as > automatic modules. We should, as much as possible, follow the recommendations > at http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html. Given > that the module names would be: > ||Artifact ID ||Module name|| > |log4j-api|org.apache.logging.log4j| > |log4j-core|org.apache.logging.log4j.core| > |log4j-1.2-api|org.apache.log4j| > |log4j-appserver|org.apache.logging.log4j.appserver| > |log4j-flume-ng|org.apache.logging.log4j.flume| > |log4j-iostreams|org.apache.logging.log4j.iostreams| > |log4j-jcl|org.apache.logging.log4j.jcl| > |log4j-jmx-gui|org.apache.logging.log4j.jmx.gui| > |log4j-jul|org.apache.logging.log4j.jul| > |log4j-nosql|org.apache.logging.log4j.nosql| > |log4j-osgi|org.apache.logging.log4j.osgi| > |log4j-sl4j-impl|org.apache.logging.log4j.slf4j.impl*| > |log4j-to-slf4j|org.apache.logging.log4j.to.slf4j| > |log4j-taglib|org.apache.logging.log4j.taglib| > |log4j-web|org.apache.logging.log4j.web| > # log4j-liquibase uses a package name outside the org.apache.logging.log4j > namespace so is not modularized. > # log4j-slf4j-impl cannot currently be modularized until the binding is > modified. It cannot have classes in the org.slf4j namespace. > # log4j-slf4j-impl and log4j-to-slf4j both use the same package name - > org.apache.logging.log4j.slf4j. This will remain the same as it will prevent > them both from being loaded at the same time. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2068) Can't set monitorInterval for composite XML configuration.
[
https://issues.apache.org/jira/browse/LOG4J2-2068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16199037#comment-16199037
]
Matt Sicker commented on LOG4J2-2068:
-
You can use the LoggerContextRule in log4j-core:test to specify the log file
name(s). That takes care of a lot of the boilerplate you have.
> Can't set monitorInterval for composite XML configuration.
> --
>
> Key: LOG4J2-2068
> URL: https://issues.apache.org/jira/browse/LOG4J2-2068
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.9.1
>Reporter: Robert Haycock
>
> When trying to combine a composite configuration with automatic reload, it
> fails to reload.
> When an {{XmlConfiguration}} is reloaded it calls
> {{XmlConfiguration.reconfigure()}} which sets the {{rootElement}} field, and
> everything is fine.
> When a {{CompositeConfiguration}} is reloaded, it doesn't call
> {{reconfigure()}} on the {{XmlConfigurations}}. This means when it tries to
> start the config {{XmlConfiguration.setup()}} is called and {{rootElement}}
> is null, resulting in an error message "No logging configuration".
> End result is the config isn't loaded and there's no more logging.
> To reproduce, it doesn't matter what is in the configurations. Just need at
> least 2 XML configs in the {{log4j.configurationFile}} property and the
> {{monitorInterval}} set.
> (Ps. my first ticket)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LOG4J2-2056) Modularize Log4j as automatic modules
[ https://issues.apache.org/jira/browse/LOG4J2-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198885#comment-16198885 ] Ralph Goers commented on LOG4J2-2056: - [~scolebou...@joda.org] Wow - Thanks for taking the time to do that! It is extremely helpful. I do have a few comments and questions: # For jars that don't make sense to modularize what would happen if the Automatic-Module-Name in the jar manifest is no value? We have the jar manifest specified in the parent pom so adding the Automatic-Module-Name header there with a variable that each module replaces works well, except for the jars that won't be modules. From what I can tell module finder would have a problem with that, but in a way that seems better than having it load it as a module using the jar's file name. # Option 1 of the Log4j 2 implementations would change how the Log4j 2 API binds to its implementation. It currently uses ServiceLoader and loads all implementations of the service it finds. Right now it only chooses one of them but it is theoretically possible that it could allow more than one logging implementation. If we went this route though, it would make me wonder if we shouldn't use ModuleFinder to locate the implementation module and then bind to only that implementation. That would be similar to how OSGi works. # I can't really select Option 1 of the SLF4J implementations without knowing what Logback is going to do. It would be strange for log4j-slf4j-impl to be named org.slf4j.impl while Logback is named something else. While it would be appropriate to think of lgo4j-slf4j-impl as an SLF4J implementation it would not be appropriate to think of it as a replacement of Logback. > Modularize Log4j as automatic modules > - > > Key: LOG4J2-2056 > URL: https://issues.apache.org/jira/browse/LOG4J2-2056 > Project: Log4j 2 > Issue Type: New Feature >Affects Versions: 2.9.1 >Reporter: Ralph Goers >Assignee: Ralph Goers > > To fully support Java 9 all Log4j jars must (at least) be packaged as > automatic modules. We should, as much as possible, follow the recommendations > at http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html. Given > that the module names would be: > ||Jar name||Module name|| > |log4j-api|org.apache.logging.log4j| > |log4j-core|org.apache.logging.log4j.core| > |log4j-1.2-api|org.apache.log4j| > |log4j-appserver|org.apache.logging.log4j.appserver| > |log4j-flume-ng|org.apache.logging.log4j.flume| > |log4j-iostreams|org.apache.logging.log4j.iostreams| > |log4j-jcl|org.apache.logging.log4j.jcl| > |log4j-jmx-gui|org.apache.logging.log4j.jmx.gui| > |log4j-jul|org.apache.logging.log4j.jul| > |log4j-nosql|org.apache.logging.log4j.nosql| > |log4j-osgi|org.apache.logging.log4j.osgi| > |log4j-sl4j-impl|org.apache.logging.log4j.slf4j.impl*| > |log4j-to-slf4j|org.apache.logging.log4j.to.slf4j| > |log4j-taglib|org.apache.logging.log4j.taglib| > |log4j-web|org.apache.logging.log4j.web| > # log4j-liquibase uses a package name outside the org.apache.logging.log4j > namespace so is not modularized. > # log4j-slf4j-impl cannot currently be modularized until the binding is > modified. It cannot have classes in the org.slf4j namespace. > # log4j-slf4j-impl and log4j-to-slf4j both use the same package name - > org.apache.logging.log4j.slf4j. This will remain the same as it will prevent > them both from being loaded at the same time. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2056) Modularize Log4j as automatic modules
[ https://issues.apache.org/jira/browse/LOG4J2-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198790#comment-16198790 ] Stephen Colebourne commented on LOG4J2-2056: I've written up a wiki page with both SLF4J and Log4J on it to try and work out what is best. There should be a common strategy between the two projects on module names. https://github.com/jodastephen/jpms-module-names/wiki/Logging-APIs The module names of the API and "replacer" projects are easy to select. "Bridge" projects are a pain, but again really have no choice (ironically, the way SLF4J replaces commons-logging is better than the way Log4J works with it, when considering JPMS modules). The key choice however is with the implementation projects which are strange because only one is allowed. For Log4J, this is log4j-core and log4j-to-slf4j. Either they both have the same module name, or they have different module names. The argument for the same module name is that only one can be active at any one time. By using the same module name, it allows the application to depend on "an implementation of Log4J" in `module-info` without explicitly specifying which one. If using different module names for each implementation, then when the application developer writes the `module-info.java` file, they are picking an explicit implementation of the API, which can't be changed at deploy time as it would be locked into a `.class` file. My gut feeling is that the former (same module name for all implementations) is correct from a modular point of view, however developers would certainly find it surprising initially because its not how maven artifacts work. Really we could do with hearing an OSGi/JBoss modules viewpoint on the choice. Anyway take a look at the link and see what you think - https://github.com/jodastephen/jpms-module-names/wiki/Logging-APIs/_edit > Modularize Log4j as automatic modules > - > > Key: LOG4J2-2056 > URL: https://issues.apache.org/jira/browse/LOG4J2-2056 > Project: Log4j 2 > Issue Type: New Feature >Affects Versions: 2.9.1 >Reporter: Ralph Goers >Assignee: Ralph Goers > > To fully support Java 9 all Log4j jars must (at least) be packaged as > automatic modules. We should, as much as possible, follow the recommendations > at http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html. Given > that the module names would be: > ||Jar name||Module name|| > |log4j-api|org.apache.logging.log4j| > |log4j-core|org.apache.logging.log4j.core| > |log4j-1.2-api|org.apache.log4j| > |log4j-appserver|org.apache.logging.log4j.appserver| > |log4j-flume-ng|org.apache.logging.log4j.flume| > |log4j-iostreams|org.apache.logging.log4j.iostreams| > |log4j-jcl|org.apache.logging.log4j.jcl| > |log4j-jmx-gui|org.apache.logging.log4j.jmx.gui| > |log4j-jul|org.apache.logging.log4j.jul| > |log4j-nosql|org.apache.logging.log4j.nosql| > |log4j-osgi|org.apache.logging.log4j.osgi| > |log4j-sl4j-impl|org.apache.logging.log4j.slf4j.impl*| > |log4j-to-slf4j|org.apache.logging.log4j.to.slf4j| > |log4j-taglib|org.apache.logging.log4j.taglib| > |log4j-web|org.apache.logging.log4j.web| > # log4j-liquibase uses a package name outside the org.apache.logging.log4j > namespace so is not modularized. > # log4j-slf4j-impl cannot currently be modularized until the binding is > modified. It cannot have classes in the org.slf4j namespace. > # log4j-slf4j-impl and log4j-to-slf4j both use the same package name - > org.apache.logging.log4j.slf4j. This will remain the same as it will prevent > them both from being loaded at the same time. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2068) Can't set monitorInterval for composite XML configuration.
[
https://issues.apache.org/jira/browse/LOG4J2-2068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198415#comment-16198415
]
Robert Haycock commented on LOG4J2-2068:
Apart from having a quick look at the code, I don't think I know it well enough
to write a unit test. Maybe someone else could?
All you need to do is have log4j2 running with 2 XML configurations and
monitorInterval set, then edit one of them.
> Can't set monitorInterval for composite XML configuration.
> --
>
> Key: LOG4J2-2068
> URL: https://issues.apache.org/jira/browse/LOG4J2-2068
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.9.1
>Reporter: Robert Haycock
>
> When trying to combine a composite configuration with automatic reload, it
> fails to reload.
> When an {{XmlConfiguration}} is reloaded it calls
> {{XmlConfiguration.reconfigure()}} which sets the {{rootElement}} field, and
> everything is fine.
> When a {{CompositeConfiguration}} is reloaded, it doesn't call
> {{reconfigure()}} on the {{XmlConfigurations}}. This means when it tries to
> start the config {{XmlConfiguration.setup()}} is called and {{rootElement}}
> is null, resulting in an error message "No logging configuration".
> End result is the config isn't loaded and there's no more logging.
> To reproduce, it doesn't matter what is in the configurations. Just need at
> least 2 XML configs in the {{log4j.configurationFile}} property and the
> {{monitorInterval}} set.
> (Ps. my first ticket)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
