[Bug] Maven artifacts should not depend on logging backend

[ppkarwasz]

Search before asking

• I had searched in the issues and found no similar issues.

Environment

Other

EventMesh version

master

What happened

Multiple EventMesh artifacts have a runtime dependency on log4j-core (a Log4j API implementation) and log4j-slf4j-impl (an SLF4J implementation), for example eventmesh-common. These can cause problems to applications that depend on EventMesh artifacts, but use a different logging backend.

Unlike logging APIs (e.g. slf4j-api, log4j-api, commons-logging, etc.) that can coexist within the same application, logging backends and bridges (e.g. logback-classic, log4j-core, log4j-to-slf4j, log4j-slf4j-impl, etc.) are mutually exclusive. A couple of examples:

• if an application has as runtime dependencies logback-classic and log4j-slf4j-impl (both are implementation of SLF4J) only one of them will work,
• if an application has as runtime dependencies log4j-to-slf4j (a bridge from Log4j API to SLF4J) and log4j-slf4j-impl (a bridge from SLF4J to Log4j API), both of them will cease to work to prevent an infinite loop.

It is easy to find such examples in practice: an application based both on zookeper and EventMesh, will have both logback-classic and log4j-core on its classpath.

To prevent this kind of conflicts, the following steps should be necessary:

• all the logging backends and bridges (an incomplete list: logback-classic, log4j-core, log4j-to-slf4j, log4j-slf4j-impl, log4j-to-jul, log4j-jul, log4j-over-slf4j) should be removed from the runtimeClasspath and moved to the testRuntimeOnly configuration,
• all log4j2.xml configuration files should be removed from the published JARs, so that they not interfere with the configuration provided by applications,
• the log4j-core, log4j-slf4j-impl and log4j-jul artifacts should be added to the TAR distribution, since it is meant to run as a standalone application.

How to reproduce

To pinpoint the affected artifacts run:

./gradlew dependencies

and check the runtimeClasspath configuration.

Debug logs

No response

Are you willing to submit PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct *

[github-actions]

Welcome to the Apache EventMesh community!!
We are glad that you are contributing by opening this issue. :D

Please make sure to include all the relevant context.
We will be here shortly.

If you are interested in contributing to our project, please let us know!
You can check out our contributing guide on contributing to EventMesh.

Want to get closer to the community?

WeChat Assistant	WeChat Public Account	Slack
		Join Slack Chat

Mailing Lists:

Name	Description	Subscribe	Unsubscribe	Archive
Users	User support and questions mailing list	Subscribe	Unsubscribe	Mail Archives
Development	Development related discussions	Subscribe	Unsubscribe	Mail Archives
Commits	All commits to repositories	Subscribe	Unsubscribe	Mail Archives
Issues	Issues or PRs comments and reviews	Subscribe	Unsubscribe	Mail Archives

[Pil0tXia]

Thank you for pointing it out! Usually third-party applications will depend on eventmesh-sdk (cf. https://github.com/apache/eventmesh/blob/master/eventmesh-sdks/eventmesh-sdk-java/build.gradle), only slf4j-api dependency is transferred from eventmesh-common.

[Pil0tXia]

We recently encountered this issue when developing EventMesh Dashboard:

The EventMesh Dashboard uses Spring Boot's default logback implement, and we have to exclude the implement artifact to avoid SLF4J: Class path contains multiple SLF4J bindings. error.