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 wrote:
>
> I would also encourage you to do the upgrade first on QA/Staging rather
> than direct
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 off
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 thi
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 ?
Thanks
—
Ing. Andrea Vettori
Responsabile Sistemi Informativi
B2BIres s.r.l.
> On 15 Dec 2021, at 17:32, Shawn Heisey wrote:
>
> On 12/14/21 10:55 PM,
On 12/14/21 10:55 PM, Soh Jia Yu, Eunice wrote:
We've implemented this step "Otherwise, remove the JndiLookup class from the classpath:
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class" from
https://logging.apache.org/log4j/2.x/security.html for /server/lib/ext.
Hi,
We've implemented this step "Otherwise, remove the JndiLookup class from the
classpath: zip -q -d log4j-core-*.jar
org/apache/logging/log4j/core/lookup/JndiLookup.class" from
https://logging.apache.org/log4j/2.x/security.html for
/server/lib/ext.
We would like to check if
/contrib/promet
