-
Notifications
You must be signed in to change notification settings - Fork 114
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Resilience4j dependency pulls in a transitive slf4j which is too old #499
Comments
Which is interesting, because I thought this should solve those kind of problems already: |
Labeled it as bug as we either have to fix it or update the get started tutorial - as it does not run out of the box right now |
I think we should add a dependency to that slf4j-api within the spring-boot-starter project, this way the version is pulled from the dependencyManagement and written to the resulting pom. I will create a PR for it. I also thought about looking into the Maven Flatten Plugin (https://stackoverflow.com/questions/75510285/dependencymanagement-unfortunately-not-transitive, https://blog.frankel.ch/maven-flatten-plugin/) but restrained from touching too much for now :-) |
There is a way to enforce dependency convergence by using the maven enforcer plugin. This will help cleaning up issues like this. |
Nice catch, I wasn't encountering this before due to the fact I always include the Spring BOM. I think your approach of adding an explicit dependency looks fine. I prefer to have that fixed now so prospects will not encounter that issue. @jonathanlukas Thats interesting will take look at that approach when I get some capacity. |
I would prefer excluding the dependency instead of managing it in our artefact. |
Could you provide an example on how we can exclude the dependency? From a first thought, we could do that, but then the customer will then be responsible (which I think is an extra work and might be a showstopper for first-time users) for putting the right version in their implementation either by hardcoding a version number, or relying on another dependency that will supersede the old sl4j in our |
You can't exclude slf4j-api as it is used by resilience4j - we just have to make sure the version compatible with the current Spring Boot setup is used. |
Running a plain worker (like https://github.com/camunda/camunda-platform-tutorials/tree/main/orchestrate-microservices/worker-java) on spring-zeebe 8.2.x or 8.3.0 will result in the following exception:
This is because in this plain worker, no Maven BOM is used to set versions, an thus resilience4j brings in a slf4j in an too old version (1.7.3 instead of 2.0.x):
When manually overwriting this version to 2.0.9 or use a Spring BOM in the worker, the problem goes away:
But I think we should actually let users don't experience this obstacle themselves and thus solve it within Spring Zeebe itself.
The text was updated successfully, but these errors were encountered: