upgrade-log4j2-2.24.2

[risdenk]

https://issues.apache.org/jira/browse/SOLR-XXXXX

This is a follow on to #2047 where biz.aQute.bnd doesn't need to be upgraded.

However running into some test failures due to concurrent modification exceptions when updating loggers in some tests.

[risdenk]

Looks like we are running into:

• ConcurrentModificationException in LoggerContext due to race condition logging-log4j2#3234
• ConcurrectModificationException while adjusting log-level in runtime logging-log4j2#3283

Once those are fixed (there is a PR it looks like) should be ok

[malliaridis]

Thanks for taking care of dependency updates during the downtime of our bot. 😄

Could you update the license files of

• slf4j-api
• jul-to-slf4j
• jcl-over-slf4j, this changed from MIT to ASL in repo, but is still using the base license in downloaded package. Not sure which one to use in this case. @janhoy any idea how to handle these cases? Prefer ASL?

Also you can remove the content of:

• slf4j-NOTICE.txt (as it does not exist anymore according to repo)
• jul-to-slf4j-NOTICE.txt (as it does not exist anymore according to repo)
• jcl-over-slf4j-NOTICE.txt (as it does not exist anymore according to repo)

And since you are already updating the libraries, you may consider merging the log4j-*-LICENSE.txt (6 files) into log4j-LICENSE.txt and log4j-*-NOTICE.txt (6 files) into log4j-NOTICE.txt, as they all share now the same license and notice file according to repo (see log4j).

I think our license file checker does not recognize the slf4j group for the jul-to-slf4j and jcl-over-slf4j libraries, otherwise we could merge these as well.

[ppkarwasz]

@risdenk,

I'll cut a 2.24.3 release on Monday. The RC should solve your problems.

[janhoy]

I have no preference when license is ambiguous. Guess whatever is in the download tar for that version is safe.

[ppkarwasz]

• jul-to-slf4j

Since you use Log4j Core in your binary distribution, you should consider using the JUL-to-Log4j API bridge instead. The artifact has two modi operandi:

• A fast bridge, which replace JUL entirely, but requires the setting of the java.util.logging.manager Java system property in your startup scripts (see Using LogManager).
• A slower bridge, similar to the one in jul-to-slf4j, but it provides direct bridging between JUL and Log4j API (without passing through SLF4J). See Using Log4jBridgeHandler.

• jcl-over-slf4j, this changed from MIT to ASL in repo, but is still using the base license in downloaded package. Not sure which one to use in this case. @janhoy any idea how to handle these cases? Prefer ASL?

Since the release of commons-logging 1.3.0, jcl-over-slf4j (as well as spring-jcl and log4j-jcl) are no longer necessary. We made a blog post about it last year.