[
https://issues.apache.org/jira/browse/SOLR-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386432#comment-16386432
]
Erick Erickson commented on SOLR-7887:
--------------------------------------
And.... This morning it doesn't even compile if you do a fresh pull from
master. IIRC the last time I updated from master was yesterday afternoon, but
that may not be entirely accurate.
NOTE: If you want to work with trying to resolve dependencies, you need to
delete all the jars in
solr/core/lib
solr/solr-ref-guide/lib
solr/server/lib/ext
solr/solrj-test-lib
and delete ~/.ivy2/cache
what happened to me was that I removed my ivy cache as a sanity check and
precommit started failing. Eventually I found that even after "ant clean-jars",
there were left-over soft links like:
./solr/core/lib/slf4j-log4j12-1.7.24.jar ->
/Users/Erick/.ivy2/cache/org.slf4j/slf4j-log4j12/jars/slf4j-log4j12-1.7.24.jar,
apparently clean-jars doesn't remove things not in the dependencies, which
makes sense.
of course since I'd cleaned my ivy cache since
/Users/Erick/.ivy2/cache/org.slf4j/slf4j-log4j12/jars/slf4j-log4j12-1.7.24.jar
wasn't there. This did NOT show up until precommit though. Whether this is the
root of my inability to start Solr is anybody's guess. And whether that's part
of my current inability to compile (although it was working fine last night) is
also a good question. Compilation over a current pull fails with:
::::::::::::::::::::::::::::::::::::::::::::::
[ivy:retrieve] :: UNRESOLVED DEPENDENCIES ::
[ivy:retrieve] ::::::::::::::::::::::::::::::::::::::::::::::
[ivy:retrieve] :: org.slf4j#slf4j-log4j12;${/org.slf4j/slf4j-log4j12}:
not found
[ivy:retrieve] :: log4j#log4j;${/log4j/log4j}: not found
Shawn:
Are you talking about one of the log4j2.xml files? If so, what I did was copy
the _same_ log4j2.xml file from into three places, example/resources,
server/resources and server/scripts/cloud-scripts.
Nobody seems to know which of those three is used at what point so I decided to
make them all the same. At least they'll be consistent. I'm perfectly open to
changing them, but having all three do different things is confusing as you
well know. Until SOLR-12008 is fully addressed, I'm opting for them all being
the same, maybe a bad call......
> 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
> Assignee: Varun Thacker
> Priority: Major
> Attachments: SOLR-7887-WIP.patch, SOLR-7887-eoe-review.patch,
> SOLR-7887-eoe-review.patch, SOLR-7887.patch, SOLR-7887.patch,
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.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
