[
https://issues.apache.org/jira/browse/LOGGING-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17789465#comment-17789465
]
Piotr Karwasz edited comment on LOGGING-187 at 11/24/23 3:47 PM:
-----------------------------------------------------------------
I agree that Commons Logging is almost ready for a new release. Recently I
added two new log factories that use Log4j API and SLF4J and have a higher
priority than the legacy one (cf. [PR
#177|https://github.com/apache/commons-logging/pull/177]).
However I don't agree on the conclusions:
* the Avalon, Lumberjack and Log4j 1.x {{Log}} implementation *must* stay,
unless we want to release a *major* version of JCL; nevertheless, we can mark
all of them as deprecated, document their removal in 2.x and *remove* them from
the default list of implementation to scan (cf.
[LogFactoryImpl#classesToDiscover|https://github.com/apache/commons-logging/blob/2a1457cb34075943e53206a753b5819f803f4dbb/src/main/java/org/apache/commons/logging/impl/LogFactoryImpl.java#L152]).
The latter will certainly fail some tests, so a PR would be useful,
* same for the group id: if we change the group id it will be an *entirely*
different artifact and current users will not be able to upgrade. There is a
largely untested [Maven relocation
feature|https://maven.apache.org/guides/mini/guide-relocation.html], but I
wouldn't rely on it,
* the new version should run on JRE 8, since it is still quite popular.
Regarding the changes in the discovery algorithm proposed above:
* Spring users will not notice them: they already use an alternative log
factory in {{spring-jcl}} that binds to either Log4j API or SLF4J with the same
rules from my PR,
* those that use Log4j Core or Logback as logging backend won't notice the
change either, since they must have Log4j API or SLF4J on the classpath,
* those that have the SLF4J binding for Log4j 1.x should not feel any
problems, since a path JCL -> SLF4J -> Log4j 1.x/Reload4j should be established
automatically,
* remains a very small group of users that use Log4j 1.x or Reload4j and don't
have SLF4J, these will be hit hard.
Therefore the release notes *should* clearly specify the upgrade procedure that
consists in adding a {{commons-logging.properties}} file to the application's
classpath with content:
{noformat}
org.apache.commons.logging.Log = org.apache.commons.logging.impl.Log4JLogger
{noformat}
(or whatever obsolete logging backend the user prefers).
was (Author: pkarwasz):
I agree that Commons Logging is almost ready for a new release. Recently I
added two new log factories that use Log4j API and SLF4J and have a higher
priority than the legacy one (cf. [PR
#177|https://github.com/apache/commons-logging/pull/177]).
However I don't agree on the conclusions:
* the Avalon, Lumberjack and Log4j 1.x {{Log}} implementation *must* stay,
unless we want to release a *major* version of JCL; nevertheless, we can mark
all of them as deprecated, document their removal in 2.x and *remove* them from
the default list of implementation to scan (cf.
[LogFactoryImpl#classesToDiscover|https://github.com/apache/commons-logging/blob/2a1457cb34075943e53206a753b5819f803f4dbb/src/main/java/org/apache/commons/logging/impl/LogFactoryImpl.java#L152]).
The latter will certainly fail some tests, so a PR would be useful,
* same for the group id: if we change the group id it will be an *entirely*
different artifact and current users will not be able to upgrade. There is a
largely untested [Maven relocation
feature|https://maven.apache.org/guides/mini/guide-relocation.html], but I
wouldn't rely on it,
* the new version should run on JRE 8, since it is still quite popular.
Regarding the changes in the discovery algorithm proposed above:
* Spring users will not notice them: they already use an alternative log
factory in {{spring-jcl}} that binds to either Log4j API or SLF4J with the same
rules from my PR,
* those that use Log4j Core or Logback as logging backend won't notice the
change either,
* remains a very small group of users that use Log4j 1.x or Reload4j, these
will be hit hard.
Therefore the release notes *should* clearly specify the upgrade procedure that
consists in adding a {{commons-logging.properties}} file to the application's
classpath with content:
{noformat}
org.apache.commons.logging.Log = org.apache.commons.logging.impl.Log4JLogger
{noformat}
(or whatever obsolete logging backend the user prefers).
> release current state of master as 1.3
> --------------------------------------
>
> Key: LOGGING-187
> URL: https://issues.apache.org/jira/browse/LOGGING-187
> Project: Commons Logging
> Issue Type: Task
> Reporter: Samael Bate
> Priority: Major
>
> master branch appears to be in a good state. Please can someone within Apache
> tag/publish a new release so that the following changes can be made as a v2:
> * Remove Avalon & Lumberjack loggers
> (https://issues.apache.org/jira/browse/LOGGING-173)
> * Replace log4j 1 with log4j 2
> (https://issues.apache.org/jira/browse/LOGGING-180,
> https://issues.apache.org/jira/browse/LOGGING-181)
> * Change _GroupId_ of maven artifact to *org.apache.commons* like other
> Apache Commons libs.
> * Potentially bump the minimum support JDK (v11 will be needed for recent
> logback)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
