[GitHub] logging-log4j2 pull request #135: [LOG4J2-2123] DefaultMergeStrategy did not...
Github user asfgit closed the pull request at: https://github.com/apache/logging-log4j2/pull/135 ---
[jira] [Resolved] (LOG4J2-2123) logger filter in composite logger not combined properly
[
https://issues.apache.org/jira/browse/LOG4J2-2123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralph Goers resolved LOG4J2-2123.
-
Resolution: Fixed
Fix Version/s: 2.10.1
Patch applied - Please verify and close.
> logger filter in composite logger not combined properly
> ---
>
> Key: LOG4J2-2123
> URL: https://issues.apache.org/jira/browse/LOG4J2-2123
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Jacob Tolar
> Fix For: 2.10.1
>
>
> When using a composite logger with DefaultMergeStrategy, logger filters
> aren't combined properly.
> Specifically, if the 'parent' configuration for the logger has no filter and
> the child configuration does, all attributes and children of the child filter
> are dropped from the composite configuration.
> For example, if my parent logger has:
> {code}
>
>
>
>
> {code}
> and the child logger has:
> {code}
>
>
> />
>
>
> {code}
> DefaultMergeStrategy creates a RegexFilter node in the composite
> configuration with no attributes. You end up getting a message like this when
> the RegexFilter is constructed:
> {code}
> 2017-11-21 12:02:26,733 main ERROR A regular expression must be provided for
> RegexFilter
> {code}
> Here:
> https://github.com/apache/logging-log4j2/blob/master/log4j-core/src/main/java/org/apache/logging/log4j/core/config/composite/DefaultMergeStrategy.java#L172-L174
> A new copy of the filter node is created, but the children and attributes
> aren't added to the new nodes.
> If the parent logger config does have a filter, it looks like it works
> correctly.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LOG4J2-2123) logger filter in composite logger not combined properly
[
https://issues.apache.org/jira/browse/LOG4J2-2123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16285530#comment-16285530
]
ASF subversion and git services commented on LOG4J2-2123:
-
Commit e937359a294971ea3c26d12bfb4c9053339ba22b in logging-log4j2's branch
refs/heads/master from [~jtolar]
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=e937359 ]
[LOG4J2-2123] DefaultMergeStrategy did not merge filters on loggers correctly
> logger filter in composite logger not combined properly
> ---
>
> Key: LOG4J2-2123
> URL: https://issues.apache.org/jira/browse/LOG4J2-2123
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Jacob Tolar
>
> When using a composite logger with DefaultMergeStrategy, logger filters
> aren't combined properly.
> Specifically, if the 'parent' configuration for the logger has no filter and
> the child configuration does, all attributes and children of the child filter
> are dropped from the composite configuration.
> For example, if my parent logger has:
> {code}
>
>
>
>
> {code}
> and the child logger has:
> {code}
>
>
> />
>
>
> {code}
> DefaultMergeStrategy creates a RegexFilter node in the composite
> configuration with no attributes. You end up getting a message like this when
> the RegexFilter is constructed:
> {code}
> 2017-11-21 12:02:26,733 main ERROR A regular expression must be provided for
> RegexFilter
> {code}
> Here:
> https://github.com/apache/logging-log4j2/blob/master/log4j-core/src/main/java/org/apache/logging/log4j/core/config/composite/DefaultMergeStrategy.java#L172-L174
> A new copy of the filter node is created, but the children and attributes
> aren't added to the new nodes.
> If the parent logger config does have a filter, it looks like it works
> correctly.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LOG4J2-2123) logger filter in composite logger not combined properly
[
https://issues.apache.org/jira/browse/LOG4J2-2123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16285531#comment-16285531
]
ASF subversion and git services commented on LOG4J2-2123:
-
Commit fe8387f74b609dcc3e7619f0bd4a30fb9dc4a037 in logging-log4j2's branch
refs/heads/master from [~ralphgoers]
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=fe8387f ]
LOG4J2-2123 - DefaultMergeStrategy did not merge filters on loggers correctly
> logger filter in composite logger not combined properly
> ---
>
> Key: LOG4J2-2123
> URL: https://issues.apache.org/jira/browse/LOG4J2-2123
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Jacob Tolar
>
> When using a composite logger with DefaultMergeStrategy, logger filters
> aren't combined properly.
> Specifically, if the 'parent' configuration for the logger has no filter and
> the child configuration does, all attributes and children of the child filter
> are dropped from the composite configuration.
> For example, if my parent logger has:
> {code}
>
>
>
>
> {code}
> and the child logger has:
> {code}
>
>
> />
>
>
> {code}
> DefaultMergeStrategy creates a RegexFilter node in the composite
> configuration with no attributes. You end up getting a message like this when
> the RegexFilter is constructed:
> {code}
> 2017-11-21 12:02:26,733 main ERROR A regular expression must be provided for
> RegexFilter
> {code}
> Here:
> https://github.com/apache/logging-log4j2/blob/master/log4j-core/src/main/java/org/apache/logging/log4j/core/config/composite/DefaultMergeStrategy.java#L172-L174
> A new copy of the filter node is created, but the children and attributes
> aren't added to the new nodes.
> If the parent logger config does have a filter, it looks like it works
> correctly.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] logging-log4j2 issue #138: POC: declarative runtime null-checks
Github user denis-zhdanov commented on the issue: https://github.com/apache/logging-log4j2/pull/138 Makes sense, thanks. This PR can be closed then as *Traute* is a *javac* plugin and that *API* is available since *javac8* ---
[GitHub] logging-log4j2 pull request #138: POC: declarative runtime null-checks
Github user denis-zhdanov closed the pull request at: https://github.com/apache/logging-log4j2/pull/138 ---
[GitHub] logging-log4j2 issue #138: POC: declarative runtime null-checks
Github user remkop commented on the issue: https://github.com/apache/logging-log4j2/pull/138 @denis-zhdanov The 1.8 javac compiler will recognize and reject new language constructs like lambdas, but it cannot check at the API (library) level. For example `Files.readAllLines(Path path)` is a new method added to the `Files` class in Java 8. If Log4j accidentally contained code that called that method, javac 8, would compile fine which is not good... ---
[GitHub] logging-log4j2 issue #138: POC: declarative runtime null-checks
Github user garydgregory commented on the issue: https://github.com/apache/logging-log4j2/pull/138 javac -target 1.7 just tells the compiler to generate 1.7 byte codes; it does nothing to avoid calling Java 8, 9 or 10 APIs. ---
[GitHub] logging-log4j2 issue #138: POC: declarative runtime null-checks
Github user denis-zhdanov commented on the issue: https://github.com/apache/logging-log4j2/pull/138 But *javac -target 1.7* provides that level of confidence, doesn't it? ---
[GitHub] logging-log4j2 issue #138: POC: declarative runtime null-checks
Github user rgoers commented on the issue: https://github.com/apache/logging-log4j2/pull/138 To be 100% certain that we didn't reference anything from Java 8 by accident. ---
[GitHub] logging-log4j2 issue #138: POC: declarative runtime null-checks
Github user rgoers commented on the issue: https://github.com/apache/logging-log4j2/pull/138 All release builds are done with the Java 7 compiler. ---
[GitHub] logging-log4j2 issue #138: POC: declarative runtime null-checks
Github user denis-zhdanov commented on the issue: https://github.com/apache/logging-log4j2/pull/138 Hey guys, Thanks for the feedback, a couple of notes: * as [mentioned in the Traute documentation](http://traute.oss.harmonysoft.tech/#3-alternatives), Lombok has a couple of limitations - it supports only Lombok *NonNull* annotation and it's a *APT*-based solution, i.e. it generates additional data (\*.class files) - *javac* plugin is more natural in this area. Regarding the quality - yes, Lombok is more mature, but it also was young and it was necessary to find host projects for it :) *Traute* already has an [extensive test suit](https://github.com/denis-zhdanov/traute/tree/master/core/test/src/test/java/tech/harmonysoft/oss/traute/test/suite) and I'm fully on it to quickly react on any new enhancement requests * as *java* is backward compatible, it's possible to compile the sources by *javac 1.8* with target version *1.7* (that is current log4j2 configuration, implied by the maven-compiler-plugin 3.7.0, so, there is no problem here) * there is no requirement to use jetbrains annotations here - *Traute* [supports](http://traute.oss.harmonysoft.tech/core/javac/#7-settings) a number of *NotNull* annotations by default and it's always possible to configure custom annotations to use (btw, jsr-305's *Nonnull* is also supported by default) ---
[jira] [Created] (LOG4NET-584) MaxSizeRollBackups can not works
sun lixiang created LOG4NET-584: --- Summary: MaxSizeRollBackups can not works Key: LOG4NET-584 URL: https://issues.apache.org/jira/browse/LOG4NET-584 Project: Log4net Issue Type: Bug Components: Appenders Affects Versions: 2.0.8 Environment: .net 4.5 Reporter: sun lixiang when set the ,the can not works. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
