i have s basic spring boot/cloud application based on
<spring-boot.version>1.5.17.RELEASE</spring-boot.version>
<spring-cloud.version>Camden.SR7</spring-cloud.version>
But i need spring-cloud-sleuth-zipkin with at least 1.3.x.
By importing 1.3.5.RELEASE i get a strange error.
It seems like the same dependency creates a convergence.
Is that easily solavble?
[WARNING]
Dependency convergence error for io.zipkin.zipkin2:zipkin:2.7.1 paths to dependency are:
+-my-fancy-service:0.0.1-SNAPSHOT
+-org.springframework.cloud:spring-cloud-sleuth-zipkin:1.3.5.RELEASE
+-io.zipkin.zipkin2:zipkin:2.7.1
and
+-my-fancy-service:0.0.1-SNAPSHOT
+-org.springframework.cloud:spring-cloud-sleuth-zipkin:1.3.5.RELEASE
+-io.zipkin.reporter2:zipkin-reporter:2.5.0
+-io.zipkin.zipkin2:zipkin:2.6.1
and
+-my-fancy-service:0.0.1-SNAPSHOT
+-org.springframework.cloud:spring-cloud-sleuth-zipkin:1.3.5.RELEASE
+-io.zipkin.reporter2:zipkin-sender-kafka11:2.5.0
+-io.zipkin.zipkin2:zipkin:2.6.1
and
+-my-fancy-service:0.0.1-SNAPSHOT
+-org.springframework.cloud:spring-cloud-sleuth-zipkin:1.3.5.RELEASE
+-io.zipkin.reporter2:zipkin-sender-amqp-client:2.5.0
+-io.zipkin.zipkin2:zipkin:2.6.1
Add a dependencyManagement entry for io.zipkin.zipkin2:zipkin:2.7.1
For me or anybody finding this thread:
Solved it by upgrading from Camden to Edgware which contains 1.3.5 (and resolving everything around that switch).
Related
I'm new to Quarkus and I'm validating the migration viability of a quite complex Spring Boot application.
For now, I'm trying to make the first step into Quarkus world, which is to get the application running on Quarkus JVM (non native option) with as little changes as possible.
After dealing with "spring-orm", "spring-jdbc", "spring-web" (client part), "spring-security" and "spring-boot" (autoconfigure and web parts) dependencies not covered by Quarkus spring extensions, now I'm facing Quarkus deployment problems like below:
[error]: Build step io.quarkus.arc.deployment.ArcProcessor#validate threw an exception: javax.enterprise.inject.spi.DeploymentException: Found 8 deployment problems:
Unsatisfied dependency for type <APP_BASE_PACKAGE>.api.rulesengine.service.RulesDomainConfiguratorService and qualifiers
Unsatisfied dependency for type <APP_BASE_PACKAGE>.api.rulesengine.service.RulesEngineService and qualifiers
Unsatisfied dependency for type <APP_BASE_PACKAGE>.api.rulesengine.service.RulesEngineStatisticService and qualifiers
Unsatisfied dependency for type <APP_BASE_PACKAGE>.api.rulesengine.jmx.DynamicJmxConfigurationProperties and qualifiers
I've noticed that it's possible to solve almost all deployment problems above by the addition of "#ApplicationScoped" (as suggested by #Turing85 here), but I've got really lost by those deployment failures conditions, and the necessity of the annotation addition, for a number of reasons, being some of them:
1- Those deployment errors are regarding services and repositories implemented on diferent modules of the same project (which are all indexed with jandex);
2- One deployment problem couldn't be solved by the addition of "#ApplicationScoped" on quite similar condition of one that was solved;
3- I was not expecting to get any errors regarding spring dependencies, or have to add any CDI annotation, considering that I'm using "quarkus-spring-*" compatibility extensions; and,
4- The deployment indicated problems cover only a small subset of all spring dependencies of the whole project. Why just them?
Am I missing something here?
Thanks and best regards.
After some attempts to solve the problem I decided to give a try and replace the "jandex-maven-plugin" by the "resources/META-INF/beans.xml" files (as the dependencies indexation option) and all unsatisfied dependencies regarding children modules of the application just vanished.
I discovered some vulnerabilities in a Spring project that use dependencies:
reactor-netty-core
reactor-netty-http
The only related import I have in the pom.xml file is:
<dependency>
<groupId>org.projectreactor</groupId>
<artifactId>reactor-spring</artifactId>
<version>1.0.1.RELEASE</version>
</dependency>
After some research, I found that there is no new version for this dependency on MavenRepository, but that there is another dependency with the same name (projectreactor).
The difference is that this dependency starts with .io instead of .org.
https://projectreactor.io/docs/core
https://projectreactor.io/docs/netty
Can you help me to understand the difference between .io and .org in this case?
And what is the best way to update this to prevent these vulnerabilities?
Have you found a vulnerability (as in security research) or do you get eg. tooling reporting a known vulnerability?
Both Spring projects and Reactor follow VMware security policy. If you've found vulnerabilities, this is the channel through which you should report them.
The reactor-netty artifacts are part of the 3rd generation of Project Reactor (the current one, with io.projectreactor base groupId).
The org.projectreactor groupId is for the 2nd generation. Reactor 2 is long discontinued (early 2015) and unsupported since then. Reactor 2 and 3 can basically be considered two entirely different libraries.
It is very weird that you'd have an application which uses reactor-netty-* and reactor-spring at the same time. If you are dealing with a Spring Framework 5 application, you can probably simply drop that dependency.
I want to reuse and centralize the utils I created for my Spring REST API for my future projects. That's why I thought I'd outsource them to my own project and make them available as a Maven dependency.
These Util files e.g. a basic service, basic controllers also contain Spring annotations, i.e. I need some Spring dependencies in my Util dependency. Now I'm a bit unsure whether I'm making a mistake or not.
First of all, I'm not sure if I should even use spring dependencies in a utility dependency or try to remove everything. Otherwise, I'll have to specify a spring version, but it might differ from the version I want to use later in the project it's included in. How am I supposed to solve this?
It is perfectly reasonable to have dependencies for your dependencies (these are called transitive dependencies). Of course, you should keep the number as low as possible, but on the other hand, you do not want to reinvent the wheel.
When somebody uses your dependency, they will automatically draw the transitive dependency on spring. Now, several cases can occur:
If this is the only reference to spring, the version is just used as you stated it.
If at some other point, a different version of spring is given, Maven dependency mediation kicks in. It decides by a "nearest is best" rule which version to take.
But: You can always set the spring version in <dependencyManagement> and then overwrite all transitively given version numbers.
That is the main concept of Maven. Your utility module must shipped together with Spring dependencies. It's called transitive dependencies.
Try to imagine that situation when all dependencies had excluded. In that case nobody will never know what kind and which version of Spring dependencies are needed.
Maven has a very good dependency conflict resolution. It's based on nearest-newest principle. So you can override those Spring versions easily and your application will use only one of that.
Take a look at these:
[1] Dependency Mechanism
[2] Dependency Mediation and Conflict Resolution
We are using Spring-test-4.0.6 jar in test scope in our project. Under same project we also have javaee-6.0 dependency in provided scope.
I am getting this error in test case
Could not initialize class org.springframework.mock.web.MockServletContext at com.sample.TestWebDOMConfiguratorMultiple.setUp(TestWebDOMConfiguratorMultiple.java:77)
Surprisingly replacing Javaee-6.0 dependency with servlet-api-3.0.1 resolves this issue.
Note: Spring-4.0.6 pom has compile time optional dependency on servlet-api-3.0.1.
Question is why is it working with servlet-3.0.1 and not with javaee 6.0 as we are trying
to replace servlet-api-3.0.1 with javaee-6.0.
Thanks in advance.
Without knowing the exact artifact that you are referring to as javaee-6.0 and without being able to see the full stack trace, it appears that your javaee-6.0 dependency contains Servlet API 3.0; whereas, spring-test-4.0.6.RELEASE explicitly requires Servlet API 3.0.1.
So that is likely the source of your problem.
Regards,
Sam
I'm in the process of moving a Java/Spring MVC app to Grails. I was able to get a couple of pages along with Spring Security working. However, when I added cxf-bundle-minimal as a dependency I started to get the errors below.
::::::::::::::::::::::::::::::::::::::::::::::
:: UNRESOLVED DEPENDENCIES ::
::::::::::::::::::::::::::::::::::::::::::::::
:: javax.ejb#ejb;3.0: not found ::
::::::::::::::::::::::::::::::::::::::::::::::
Exception starting filter springSecurityFilterChain
org.springframework.beans.factory.NoSuchBeanDefinitionException:
No bean named 'springSecurityFilterChain' is defined
Now, even if I remove the dependency the error continues. Anyone know what the cause of the problem is and how to resolve it? My dependency list follows.
dependencies {
runtime 'mysql:mysql-connector-java:5.1.12'
compile('log4j:log4j:1.2.16',
'org.apache.cxf:cxf-bundle-minimal:2.2.9',
'org.springframework:spring-beans:3.0.2.RELEASE',
'org.springframework:spring-context:3.0.2.RELEASE',
'org.springframework:spring-core:3.0.2.RELEASE',
'org.springframework:spring-jdbc:3.0.2.RELEASE',
'org.springframework.security:spring-security-core:3.0.2.RELEASE',
'org.springframework.security:spring-security-config:3.0.2.RELEASE',
'org.springframework.security:spring-security-web:3.0.2.RELEASE')
}
This isn't what you want to hear, I'm sure, but nearly every time I've strayed from the default Grails configuration (using Maven or the native build), I've found myself beating my head against these types of configuration problems. I don't have a magical solution for you, but I'd first run a dependency report to see what the graph looks like (http://grails.org/doc/1.3.x/). After that it becomes detective work and more than a little trial-and-error. Anyway, start with the dependency report and see what it shows. Good luck.
Chances are you need to add a new maven repo dependency into your BuildConfig.groovy file. Find (or create) a repo that has the jar files that are missing, and add it in. By default the jboss maven repo is commented out, but it might have what you're looking for as a starting place.
I had a similar issue today. After some research online I decided that this problem may be caused by one of my plugin's dependencies, but I didn't know which one. How I solved (sidestepped) it was to go to "application.properties" and commented out the plugins that were non-essential.
Obviously this does not solve the underlying dependency problem, unless you can live without those plugins.
I understand your frustrations, believe me. If you find a better solution please post it!