We are unable to start our Spring Boot application (version 2.1.9.RELEASE) when using Hazelcast (artifact hazelcast-all and version 4.1). I get error
An attempt was made to call a method that does not exist. The attempt was made from the following location: org.springframework.boot.actuate.metrics.cache.HazelcastCacheMeterBinderProvider.getMeterBinder(HazelcastCacheMeterBinderProvider.java)
The following method did not exist: com.hazelcast.spring.cache.HazelcastCache.getNativeCache()Lcom/hazelcast/core/IMap;
The method's class, com.hazelcast.spring.cache.HazelcastCache, is available from the following locations: jar:file:<path>/.m2/repository/com/hazelcast/hazelcast-all/4.1/hazelcast-all-4.1.jar!/com/hazelcast/spring/cache/HazelcastCache.class
It was loaded from the following location: file:<path>/.m2/repository/com/hazelcast/hazelcast-all/4.1/hazelcast-all-4.1.jar
Action: Correct the classpath of your application so that it contains a single, compatible version of com.hazelcast.spring.cache.HazelcastCache We checked for IMap class - package com.hazelcast.map.IMap. Any solution/suggestion on this issue?
Trying to see if the following compatibility works.
Just looking at https://mvnrepository.com/artifact/org.springframework.boot/spring-boot-actuator-autoconfigure/2.1.9.RELEASE , the HazelCast version is 3.11.4. Can you change the version of hazelcast from 4.1 to 3.11.4 (on the POM) and try it again.
<dependency>
<groupId>com.hazelcast</groupId>
<artifactId>hazelcast-all</artifactId>
<version>3.11.4</version>
</dependency>
Related
I'm upgrading a set of legacy applications to Spring Boot 2.4.0, running on OpenJDK 8, deployed to Pivotal Cloud Foundry.
The app and all its unit tests ran perfectly under Spring 2.3.4-RELEASE before I started this upgrade.
There was work to be done right off the bat: Spring Boot 2.4.0 brings in JUnit 5.x, so I had to fix all the JUnit 4.x tests to use the new annotations and classes.
After fixing all the tests I tried to run in IntelliJ 2020.2. All the tests failed, for the same reason: java.lang.IllegalStateException: Failed to load ApplicationContext. The root of the stack trace gives this cause:
Caused by: java.lang.ClassNotFoundException: org.springframework.boot.context.properties.ConfigurationBeanFactoryMetadata
They removed a fundamental class from Spring Boot for the sake of Kubernetes, from the sound of it. I'm not sure I see why.
I did a Google search and found this explanation and fix.
I added spring.config.use-legacy-processing to my application.yml and a test application.properties file:
spring:
config:
use-legacy-processing: true
Still no joy - all the tests fail.
I'm confused by other links I've seen. Is this an issue with spring-cloud-dependencies? I'm reading that there might an issue with the Hoxton version. Do I need to add it to my app? It never needed this dependency before the upgrade:
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-dependencies</artifactId>
<version>Hoxton.SR9</version>
<type>pom</type>
<scope>import</scope>
</dependency>
The problem is bigger than the tests. If I ignore them and try to run the app I still fail:
ERROR [main]: Application run failed |ApplicationName=Risk_Advisor | sourcedfrom=ERROR
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'configurationPropertiesBeans' defined in class path resource [org/springframework/cloud/autoconfigure/ConfigurationPropertiesRebinderAutoConfiguration.class]: Post-processing of merged bean definition failed; nested exception is java.lang.IllegalStateException: Failed to introspect Class [org.springframework.cloud.context.properties.ConfigurationPropertiesBeans] from ClassLoader [sun.misc.Launcher$AppClassLoader#18b4aac2]
The root cause is the same:
java.lang.NoClassDefFoundError: org/springframework/boot/context/properties/ConfigurationBeanFactoryMetadata
when ever you do upgrades on spring, pls always look at the spring / cloud compatibility matrix and then upgrades the versions for both spring and cloud accordingly:
Also, pls note that you may not have added spring cloud as direct dependency but it may be coming into your final jar as a transitive dependency so its always better to add below spring cloud dependency as direct dependency management in your pom to stay away from any conflicts:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-dependencies</artifactId>
<version>${spring.cloud-version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
I got the same error when migrating to Spring Boot 2.4.4 which forced me to migrate to Spring Cloud 2020.0.1 as well. In my case, the error was due to Bootstrap, provided by spring-cloud-commons, not being any longer enabled by default. I had to re-enabled it by adding the following new starter in my build.gradle file as stated here:
implementation 'org.springframework.cloud:spring-cloud-starter-bootstrap'
You say your app doesn't use Spring Cloud, so I'm not sure why you ended up facing which seems to be the same issue. Hopefully this workaround might work for you and help out others using Spring Cloud.
To fix the failing JUnit 4 tests, I have just added it as a dependency:
testImplementation 'junit:junit:4.13'
I had the same error for JUnit 4 tests after migration my project to Spring Boot 2.5.6. Adding JUnit 4 dependencies did not fix this error as well as migration JUnit 4 tests to JUnit 5. My project does not define Spring Cloud dependencies in build.gradle so in order to find where those dependencies come from I simply ran gradle command:
gradle dependencyInsight --dependency org.springframework.cloud
and saw that spring cloud dependencies were pulled within one of the custom libraries. Upgrade spring cloud dependencies to a compatible version there and reimport custom library fixed the error.
I am using spring boot security version 2.2.5.RELEASE in that , I am creating a custom password encoder with Argon2PasswordEncoder as my password encoder.
In this when i run, can see following error in the Argon2PasswordEncoder.java where i can see these two imports are missing,
import org.bouncycastle.crypto.generators.Argon2BytesGenerator;
import org.bouncycastle.crypto.params.Argon2Parameters;
Error:
java.lang.NoClassDefFoundError: org/bouncycastle/crypto/params/Argon2Parameters$Builder
at org.springframework.security.crypto.argon2.Argon2PasswordEncoder.encode(Argon2PasswordEncoder.java:78) ~[spring-security-core-5.2.2.RELEASE.jar:5.2.2.RELEASE]
at com.custom.CustomPasswordEncoder.encode(CustomPasswordEncoder.java:11)
Please suggest me want to do, am I missing some dependency or its the spring boot version issue. And also how to overcome.
Many thanks.
I got the issue. for the version 2.2.5 springboot we need to explicitly add the dependency for Argon2BytesGenerator, Argon2Parameters nt found issue, since its not included in this version.
<dependency>
<groupId>org.bouncycastle</groupId>
<artifactId>bcprov-jdk15on</artifactId>
<version>1.64</version>
</dependency>
After configuring spring-session-data-redis in a demo spring-boot project, bootRun task fails with the following message:
***************************
APPLICATION FAILED TO START
***************************
Description:
Parameter 0 of method redisTemplate in org.springframework.boot.autoconfigure.data.redis.RedisAutoConfiguration required a bean of type 'org.springframework.data.redis.connection.RedisConnectionFactory' that could not be found.
- Bean method 'redisConnectionFactory' not loaded because #ConditionalOnClass did not find required classes 'org.apache.commons.pool2.impl.GenericObjectPool', 'redis.clients.jedis.Jedis'
- Bean method 'redisConnectionFactory' not loaded because #ConditionalOnClass did not find required class 'io.lettuce.core.RedisClient'
Action:
Consider revisiting the entries above or defining a bean of type 'org.springframework.data.redis.connection.RedisConnectionFactory' in your configuration.
What I've done (a.k.a. steps to reproduce):
1. Used Spring Initializr to create a [Gradle with Java and Spring Boot 2.1.0 M1 + Web dependency] project.
2. Followed the Spring Session - Spring Boot instructions to configure Spring Session. More specifically:
- added compile 'org.springframework.session:spring-session-data-redis'
to build.gradle's dependencies block
- configured the store type by adding spring.session.store-type=redis to application.properties file
- configured the connection
properties (in application.properties file): spring.redis.host,
spring.redis.password and spring.redis.port with relevant values
3. Executed ./gradlew bootRun from the root of the project and received the above error
Questions:
1. As far as I'm understand from the error message, RedisConnectionFactory failed to load because it can't find neither Jedis nor Lettuce drivers. Shouldn't spring-session-data-redis bring one of those drivers by default?
2. How to resolve this issue in case I want to use the Jedis driver?
3. How to resolve this issue in case I want to use the Lettuce driver?
1.
As #M.Deinum mentioned, spring-session-data-redis (version 2.1.0.M1) doesn't pull Jedis or Lettuce drivers.
2.
Add the latest Jedis driver as explicit dependency:
dependencies {
// ...
compile 'redis.clients:jedis:2.9.0'
}
3.
Either add spring-boot-starter-data-redis (which pulls in Lettuce driver) or the latest Lettuce driver as explicit dependency:
dependencies {
// ...
compile 'org.springframework.boot:spring-boot-starter-data-redis'
// OR
compile 'io.lettuce:lettuce-core:5.0.5.RELEASE'
}
There is 2 implementation of RedisConnectionFactory are comes with spring-session-data-redis
(1) lettuce (default) - https://github.com/spring-projects/spring-session/issues/789
(2) Jedis
Since lettuce & Jedis dependency are optional u have to have explicit dependency. u can put dependency to either one of it. (u can have both but Spring redis implementation stater used lettuce as a default implementation)
Example:
<dependency>
<groupId>redis.clients</groupId>
<artifactId>jedis</artifactId>
<version>x.x.x</version>
</dependency>
<dependency>
<groupId>io.lettuce</groupId>
<artifactId>lettuce-core</artifactId>
<version>x.x.x</version>
</dependency>
I am using oracle DB to connect with my java code on below used platform:
STS- 3.8.2
Spring -2.0.0.0 release
Maven
Oracle database XE version.
While running the spring boot app,I am getting error of jdbc driver not found for database connection string.
I tried to resolve the same by adding all related dependency, however none of them showing me valid, and also it is unable to download required jar during maven build.
I have also tried manually placing the jars in ./m2 directory by downloading from open source, but still not working.
Below is the maven dependency of Oracle-connector. Oracle connector is
missing so it is giving this error.
<dependency>
<groupId>com.oracle</groupId>
<artifactId>ojdbc14</artifactId>
<version>10.2.0.3.0</version>
</dependency>
We have a maven project to develop a jersey 2.0 REST service, on Eclipse (kepler)
<dependency>
<groupId>org.glassfish.jersey.containers</groupId>
<artifactId>jersey-container-servlet-core</artifactId>
<version>2.9.1</version>
</dependency>
In conjunction with:
java8
tomcat7
When deploying the web application (using $ mvn install && mvn -X tomcat7:redeploy) we get the below exception:
Caused by: java.lang.UnsupportedClassVersionError: org/glassfish/jersey/servlet/init/JerseyServletContainerInitializer : Unsupported major.minor version 51.0 (unable to load class org.glassfish.jersey.servlet.init.JerseyServletContainerInitializer)
at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2840)
I examined the MANIFEST file in the org.glassfish.jersey.containers jar, and (as suspected) it says build on 1.7 JDK
Tomcat logs confirm that it uses java8 itself
We cannot move back to java8. Is there a way/hack we can get past this error?
From tomcat 7.0.26, I upgraded to next version > Tomcat 7.0.47, to see if that helps.
Things started working magically. Deployed app successfully
Would be glad if someone can explain how the same plugin started to ignore jdk versions, just due to a change in tomcat version.