Do not require java.desktop

[jakub-id]

When using log4j2 2.25.0 in a backend vert.x application running on a custom JRE created via jlink it's necessary to include the java.desktop module otherwise the following exception is thrown during log4j initialization:

Exception in thread "main" java.lang.NoClassDefFoundError: java/beans/PropertyChangeEvent

Please consider making dependency on java.beans (part of java.desktop) optional or allow exclusion via maven. java.desktop is the second biggest standard module after java.base and it should not be required to include it in backend applications.

[ppkarwasz]

Hi @jakub-id,

Thanks for raising this. We’re aware of the dependency on PropertyChangeEvent. Since this class is part of the public API of LoggerContext, we couldn’t remove it in the 2.x line without introducing breaking changes.

That’s why the dependency was removed in version 3.x, which now relies only on java.base (with an optional dependency on java.xml). We’re currently evaluating whether the 3.x line is ready for a stable 3.0.0 release, so it would be very helpful if you could try 3.0.0-beta3 and share your feedback. Most of the changes are related to the modularization of the logging implementation: see our upgrade instructions for details.

For context: PropertyChangeEvent was introduced into Log4j long before Java 9 and the module system were released.

[jakub-id]

Hi @ppkarwasz,

Thanks, looking forward to 3.0 then. I gave it a shot with our application but vert.x doesn't like it:

 Caused by: java.lang.ExceptionInInitializerError: Exception java.lang.NoClassDefFoundError: Could not initialize class io.vertx.core.logging.LoggerFactory [in thread "main"]
                at io.vertx.core.impl.logging.LoggerFactory.getLogger(LoggerFactory.java:26)
                at io.vertx.core.impl.AddressResolver.<clinit>(AddressResolver.java:40)
                at io.vertx.core.dns.AddressResolverOptions.<clinit>(AddressResolverOptions.java:94)
                at io.vertx.core.VertxOptions.<init>(VertxOptions.java:144)
                at io.vertx.core.Vertx.vertx(Vertx.java:141)

This is vert.x 4.5.20, we're going to migrate to 5.x in the coming days so I'll give it another try.

[ppkarwasz]

Hi @jakub-id,

Can you check why the initialization of io.vertx.core.logging.LoggerFactory fails? If it is due to some problem in the initialization of o.a.l.log4j.LogManager, we are happy to fix it.

[vietj]

@ppkarwasz @jakub-id happy to improve vertx to support log4j3, if you could provide more details about the issue so we can determine what is the best option to support this

[jakub-id]

@ppkarwasz @vietj as mentioned on eclipse-vertx/vert.x#5689 the problem seems to be a missing release artifact for log4j-slf4j-impl 3.0.0-beta-3 release.

[vy]

@jakub-id, starting with version 2.24.0, Log4j API is embraced as the target logging API for both Log4j 2 and Log4j 3. Hence, Log4j 3 does not contain a Log4j API module, but instead implements "the" Log4j API developed in Log4j 2 branch. This ensures Log4j 2 users can safely migrate to Log4j 3 without any Log4j API compatibility concerns. (See Log4j 3 API docs.) As a result, Log4j 3 does not ship a separate log4j-slf4j-impl, which bridges SLF4J calls to Log4j API, and you can safely use log4j-slf4j-impl-2.x in Log4j 3. But we strongly recommend our users to, instead of explicitly providing each artifact version, use log4j-bom (see Log4j 3 BOM docs) and leverage the dependencies managed by it.

@jakub-id, would you mind retrying your experiment after importing log4j-bom and removing explicit version numbers, please?

[jakub-id]

@vy Thanks, we already use the BOM: https://github.com/indexdata/reservoir/blob/0a532333a8c5a1fdd91eaf9136eb64d69a39a193/pom.xml#L50 and we don't use explicit version in the dependency section. As, mentioned in the vert.x ticket 3.0.0-beta2 works fine but 3.0.0-beta3 fails. I am not ruling out that we have something wrong in our POM but there's clearly a difference between beta2 and beta3.