[
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:13 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 the no longer
supported log4j 1.2 version.
But the way this is being done 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-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?
> 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)
