Hello, yesterday I replaced the jars from 2.13.2 to 2.16 and so far no issues.
— Ing. Andrea Vettori Responsabile Sistemi Informativi B2BIres s.r.l. > On 15 Dec 2021, at 18:58, Alessandro Benedetti <a.benede...@sease.io> wrote: > > 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 <apa...@elyograg.org> 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 >> >>
