[
https://issues.apache.org/jira/browse/SOLR-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16334774#comment-16334774
]
Steve Rowe commented on SOLR-7887:
----------------------------------
bq. 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.
>From the latest patch:
{noformat}
--- solr/solr-ref-guide/ivy.xml (date 1516411619000)
[...]
- <dependency org="log4j" name="log4j" rev="${/log4j/log4j}" conf="compile"/>
+ <dependency org="org.apache.logging.log4j" name="log4j-api"
rev="${/log4j/log4j}" conf="compile"/>
+ <dependency org="org.apache.logging.log4j" name="log4j-core"
rev="${/log4j/log4j}" conf="compile"/>
{noformat}
This will fail precommit, which requires that all {{rev}} values are exactly to
{{/<org>/<name>}}. The canonical way of dealing with shared versions is to
declare a {{<prefix>.version}} property in {{ivy-versions.properties}} and then
use it, rather than literal versions, as the value for the properties that
should share it. E.g.:
{noformat}
com.carrotsearch.randomizedtesting.version = 2.5.3
/com.carrotsearch.randomizedtesting/junit4-ant =
${com.carrotsearch.randomizedtesting.version}
/com.carrotsearch.randomizedtesting/randomizedtesting-runner =
${com.carrotsearch.randomizedtesting.version}
{noformat}
> 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,
> 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
