You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Shawn Heisey (JIRA)" <ji...@apache.org> on 2018/01/20 20:09:00 UTC
[jira] [Comment Edited] (SOLR-7887) Upgrade Solr to use log4j2 --
log4j 1 now officially end of life
[ https://issues.apache.org/jira/browse/SOLR-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16333289#comment-16333289 ]
Shawn Heisey edited comment on SOLR-7887 at 1/20/18 8:08 PM:
-------------------------------------------------------------
General observation about the ivy versions:
I don't think there should be separate version strings for each component in a multi-jar system like log4j. It would be extremely unlikely for us to *ever* incorporate different versions of each of those components.
For dependencies like httpcomponents, separate strings do make sense, because that project actually does have entirely separate source repositories and releases for the different jars they maintain, and the latest version numbers do not always match.
Digesting all that into advice, which you're free to take or ignore:
I think that all of the log4j components should use a single property for their version, instead of having "/log4j/log4j-api", "/log4j/log4j-core", etc.
was (Author: elyograg):
General observation about the ivy versions:
I don't think there should be separate version strings for each component in a multi-jar system like log4j. It would be extremely unlikely for us to *ever* incorporate different versions of each of those components.
For dependencies like httpcomponents, separate strings do make sense, because that project actually does have entirely separate source repositories and releases for the different jars they maintain, and the latest version numbers do not always match.
Digesting all that into advice, which you're free to take or ignore:
I think that all of the log4j components should use a "/log4j/log4j" property for their version, instead of having "/log4j/log4j-api", "/log4j/log4j-core", etc.
> Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
> ----------------------------------------------------------------
>
> Key: SOLR-7887
> URL: https://issues.apache.org/jira/browse/SOLR-7887
> Project: Solr
> Issue Type: Task
> Affects Versions: 5.2.1
> Reporter: Shawn Heisey
> Priority: Major
> Attachments: SOLR-7887-WIP.patch, SOLR-7887.patch, SOLR-7887.patch
>
>
> The logging services project has officially announced the EOL of log4j 1:
> https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces
> In the official binary jetty deployment, we use use log4j 1.2 as our final logging destination, so the admin UI has a log watcher that actually uses log4j and java.util.logging classes. That will need to be extended to add log4j2. I think that might be the largest pain point to this upgrade.
> There is some crossover between log4j2 and slf4j. Figuring out exactly which jars need to be in the lib/ext directory will take some research.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org