ppkarwasz opened a new issue, #4700: URL: https://github.com/apache/eventmesh/issues/4700
### Search before asking - [X] I had searched in the [issues](https://github.com/apache/eventmesh/issues?q=is%3Aissue) 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`](https://mvnrepository.com/artifact/org.apache.eventmesh/eventmesh-common/1.10.0-release). 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`](https://mvnrepository.com/artifact/org.apache.zookeeper/zookeeper/3.9.1) 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: ```sh ./gradlew dependencies ``` and check the `runtimeClasspath` configuration. ### Debug logs _No response_ ### Are you willing to submit PR? - [X] Yes I am willing to submit a PR! ### Code of Conduct - [X] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct) * -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@eventmesh.apache.org.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@eventmesh.apache.org For additional commands, e-mail: issues-h...@eventmesh.apache.org
