Avoid levels like INFO#org.apache.log4j.Level

[jonasrutishauser]

If somebody (for example an external library) uses the deprecated Priority class there will be a custom level created even though there already exists a corresponding level.

[github-actions]

Job	Requested goals	Build Tool Version	Build Outcome	Build Scan®
build-macos-latest	clean install	3.9.8	✅
build-ubuntu-latest	clean install	3.9.8	✅
build-windows-latest	clean install	3.9.8	❌

Generated by gradle/develocity-actions

[ppkarwasz]

@jonasrutishauser,

Nice catch!

Looking at the o.a.l.Priority class there are other things that can go wrong:

1. Priority.version2Level can be null. This might lead to incorrect filtering of Priority instances (possibly even an NPE). Can you create a new package-private constructor that always sets this field to a non-null value:

   this.version2Level = version2Equivalent != null ? version2Equivalent : OptionConverter.createLevel(this);

2. The Priority.FATAL, Priority.ERROR and so on fields reference the Level subclass, which might lead to class loading deadlocks on some JVMs (or they might just be null on others). Can you create them using the new constructor instead?
3. Can you add test cases to LevelTest and PriorityTest to check if all the constants have the expected Log4j 2 level?

[ppkarwasz]

@jonasrutishauser,

Thank You for your contribution!