[ https://issues.apache.org/jira/browse/LOG4J2-3467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17563784#comment-17563784 ]
Alexander Picoli commented on LOG4J2-3467: ------------------------------------------ My two cents: I do understand that to have a real 100% log4j1 compatibility layer has operational advantages for people only wanting to get rid of a no longer supported log4j version. But this breaks the log4j 2 contract in many places: it is not expected that compatibility layer apis, like the jcl-api , or jul-api, to suddenly allow people to override log4j2 configuration options. The issue already start at the pom.xml : a compatibility layer with "third party" loggers should ONLY use the api, not core features. [https://github.com/apache/logging-log4j2/blob/release-2.x/log4j-1.2-api/pom.xml#L42] It seems to me that what is being tried is to make log4j2 a logj1 with another name. That is, unconsciously what is being tried is to make a second core: it should be dealt as such, perhaps as another project/jar? Who is responsible for configuring log4j2 hard facts (where files go, will we use console, and so on)? log4j-core. Not log4j-api or any other compatibility layer. What if suddenly I change the other compatibility apis, like log4j-jul or log4j-jcl to also reconfigure logging? What a mess this will become? > Update from Log4J 2.17.1 to 2.17.2 breaks application > ----------------------------------------------------- > > Key: LOG4J2-3467 > URL: https://issues.apache.org/jira/browse/LOG4J2-3467 > Project: Log4j 2 > Issue Type: Bug > Components: Core > Affects Versions: 2.17.2 > Reporter: Alexander Veit > Priority: Major > > We have an application that uses a third-party library which seems to > reconfigure Log4J according to its needs. This worked for quite some years > with various Log4J versions. > After upgrading from Log4J 2.17.1 to 2.17.2 a call to the library immediately > stops logging completely in the sense that no further logging is performed > until restarting the JVM. > We've tried to identify the change that leads to the problem. Our best guess > is PropertyConfigurator, line 164 in > https://github.com/apache/logging-log4j2/commit/73a2cd1cd0e94c7f4f36e4ac9dc72380d30750ef#diff-607596a6cadd10faf2dbeefc4e03092264b8e0dbe23fb89ffa6505d644602c9dR164 > Note that according to semantic versioning such breaking changes should not > occur when only the patch version is incremented. ;-) -- This message was sent by Atlassian Jira (v8.20.10#820010)