[
https://issues.apache.org/jira/browse/LOG4J2-3467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17563784#comment-17563784
]
Alexander Picoli edited comment on LOG4J2-3467 at 7/7/22 1:04 PM:
------------------------------------------------------------------
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-1.2-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?
was (Author: JIRAUSER292245):
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)
