I would also encourage you to do the upgrade first on QA/Staging rather than directly on production, where possible. This could prevent nasty binary incompatibilities where the Solr build expects certain methods from the compiled log4j library, that mismatch with the upgraded jar. And a crashed offline production environment is definitely not better than a potentially vulnerable one :)
Cheers -------------------------- Alessandro Benedetti Apache Lucene/Solr Committer Director, R&D Software Engineer, Search Consultant www.sease.io On Wed, 15 Dec 2021 at 16:54, Shawn Heisey <[email protected]> wrote: > On 12/15/21 9:41 AM, Ing. Andrea Vettori wrote: > > Hello, is it safe to simply replace the jars in the solr lib/ext folder > with version 2.16 or are they hardcoded in scripts or meta-inf files ? > > > This appears to work correctly if the original version of log4j included > was 2.14.1. I have done this and had no problems. I replaced it with > 2.15.0 as 2.16.0 had not yet come out when I did that testing. > > But I have not tried it with Solr versions shipping with any log4j > version other than 2.14.1, or with a 2.16.0 replacement. I have no idea > whether that would work. If the log4j team have done a good job of > keeping the API stable, I think it would work, but I do not have any > knowledge about that. You would be better off asking the log4j project > about API compatibility between versions. > > Thanks, > Shawn > >
