I am using spring 5.3.7
and when I start my application, it returns the error below:
Instantiation of bean failed; nested exception is
org.springframework.beans.BeanInstantiationException: Failed to instantiate
[org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter]:
Constructor threw exception; nested exception is java.lang.NoSuchFieldError:
com/fasterxml/jackson/annotation/JsonInclude$Include.USE_DEFAULTS
I am using jackson-annotations-2.10.3.jar which implements the USE_DEFAULTS Enum.
I hope some one can help me.
I am not sure, but you should once check for the annotations like #Service, #Controller, #Respository, there are chances that you have missed any one of the annotations. just check it carefully, it might help you out.
To deal with this error, we have to clear all .class files and recompile to ensure that all files are up to date.
If this error still exists at runtime, it may be that the dependency referenced at compile time is different from the runtime version. Here, it is necessary to check whether the various paths and versions are wrong.
Maven projects generally execute mvn clean.
Hope your problem can be solved
Try cleaning your old build and rebuild your project, atleast it works for me!
Related
I am developing a simple maven + spring application and i am getting the following error. It says two of my classes have a conflict. so i deleted the second class but i am still getting the same error. I tried restarting the server but it still says my class exists. Can somebody help?
Exception while loading the app : java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: org.springframework.beans.factory.BeanDefinitionStoreException: Failed to parse configuration class [com.nibm.config.RootConfig]; nested exception is org.springframework.context.annotation.ConflictingBeanDefinitionException: Annotation-specified bean name 'employeeController' for bean class [com.nibm.hibernate.controller.EmployeeController] conflicts with existing, non-compatible bean definition of same name and class [com.nibm.controller.EmployeeController]
I was able to solve a similar problem by using IntelliJ's function "Rebuild".
The reason was an orphan .class file after the corresponding .java file had already been deleted.
You get the exception because you have two spring beans of the same class.
This exception is thrown by
org.springframework.context.annotation.ClassPathBeanDefinitionScanner#isCompatible
And looking at that implementation it looks as if you create a bean of type EmployeeController in your RootConfig and additionally by ComponentScan.
To fix the problem remove the bean from the RootConfig or change your ComponentScan, so this bean is not found by it.
You can set a breakpoint in the constructor of EmployeeController. From the stack you can get more information about how and why the bean is created.
I faced the same problem and it was because class with same name exist at two locations as mentioned in the Exception itself which are conflicting and after removing one issue got fixed.
I was getting this same ConflictingBeanDefinitionException..."conflicts with existing, non-compatible bean definition of same name and class" when running JUnit tests with #RunWith(SpringRunner.class)/ #SpringBootTest from inside Intellij.
Execution via gradle:build of the same tests were running fine.
This began to happen after I had refactored the packaging of several #Components which lead me to believe something was holding a reference to the class under it's previous package name.
No amount of gradle build/clean would seem to clear it.
Doing a Build -> Rebuild Project in IntelliJ was what cleared this issue for me.
We've been using mule-module-redis-3.3.3-SNAPSHOT in production with mule 3.4.2 (standalone EE) for about two years now; works great, thanks!
With mule-module-redis-3.4.0, our project's maven compile is ok (yes, we've refactored our code to use the different parameter signatures in some of the RedisModule methods).
But we have been stymied so far with following error below when running any integration test within the maven build. (Our integration test classes simply extend mule's FunctionalTestCase class.)
The one difference we've noticed for the redis-connector 3.4.0 is the RedisModule.set() method has an #Inject annotation; wondering if there could be some dependency conflict or missing dependency/configuration we might be missing?
"... Error creating bean with name 'globalredis': Injection of autowired dependencies failed; nested exception is org.springframework.beans.factory.BeanCreationException: Could not autowire method: public byte[] org.mule.module.redis.RedisModule.set(java.lang.String,java.lang.Integer,boolean,java.lang.String,org.mule.api.MuleEvent); nested exception is org.springframework.beans.factory.NoUniqueBeanDefinitionException: No qualifying bean of type [java.lang.String] is defined: expected single matching bean but found 3: applicationVersion,mysqlPort,testConversionSendToBillingEnabled (org.mule.api.lifecycle.InitialisationException)"
[I've had good suggestions, without success so far :( on the Mule Community Forum with this issue, so hoping there might be others more involved with the mule redis-connector who are here. Thanks!]
My problem is that I'm building spring-boot project and I'm using class A from some other project which use log4j 1.2.8. When I force spring to use log4j 1.2.8 I have following error:
org.springframework.beans.factory.BeanCreationException: Error
creating bean with name 'jettyEmbeddedServletContainerFactory' defined
in class path resource
[org/springframework/boot/autoconfigure/web/EmbeddedServletContainerAutoConfiguration$EmbeddedJetty.class]:
Initialization of bean failed; nested excepti
on is org.springframework.beans.factory.BeanCreationException: Error
creating bean with name
'org.springframework.boot.autoconfigure.web.ErrorMvcAutoConfiguration':
Injection of autowired dependencies failed; nested exception is
org.springframework.beans.factory.BeanCreationException: Could not
autowire field: private
org.springframework.boot.autoconfigure.web.ServerProperties
org.springframework.boot.autoconfigure.web.ErrorMvcAutoConfiguration.properties;
nested exception is
org.springframework.beans.factory.BeanCreationException: Error
creating bean with name 'serverProperties' defined in class path
resource
[org/springframework/boot/autoconfigure/web/ServerPropertiesAutoConfiguration.class]:
Initialization of bean failed; nested exception is
java.lang.NoSuchFieldError: TRACE
Spring need at least log4j 1.2.12, so when I use this version of log4j my A class have follwing error:
java.lang.NoSuchMethodError:
org.apache.log4j.LogManager.exists(Ljava/lang/String;)Lorg/apache/log4j/Logger;
There is any solution other than upgrade of my A class log4j? Maybe there is any way to force at runtime some classes should use log4j 1.2.8 and other would use 1.2.12 ?
OSGI is such kind of technology which you can have multiple versions of same library in one JVM runtime.
However, it's overkilled for most of cases. Same suggestion as others, upgrading your source code would be much cheaper way.
Solution for this problem is easy. I mentioned in comment that spring use log4j-over-slf4j which doesn't implement LogManager.exists method which my Class is using. I've just excluded from my project(gradle) log4j-over-slf4j and added dependency to log4j as below.
configurations {
compile.exclude module: 'log4j-over-slf4j'
}
compile group: 'log4j', name: 'log4j', version: '1.2.17'
The easiest solution is to upgrade your project A. Updating the logging library is a minor risk, fiddling with different library versions can be tedious and confusing.
Disclaimer: I'm not familiar with spring-boot, maybe it has a clever way of dealing with this issue.
I would highly recommend to upgrade the class that is making the problems with an older log4j version. Every thing you could do, at my knowledge, would be way more complicated then upgrading. You could split up into 2 diffrent projects in their own classloader or something like that.. basicly that is what something like tomcat does to achieve multiple java web applications.. but then you have to look how both communicate etc etc... so I suppose that the most solutions will make it more complicated than it needs to be, or should be
I'm using Spring 3.1.1.RELEASE and Hibernate 4.1.10.FINAL in a Building Block on Blackboard Learn and getting the following exception:
java.lang.NoClassDefFoundError: Could not initialize class org.hibernate.cfg.PropertyContainer
This seems to be a classpath issue, and so I did some digging and added the suggested libraries from this post but the same error occurs.
So my classpath now contains the necessary dependencies, but I am still getting the exception. What are some additional points I can look at to identify and resolve this issue?
Edit: I've verified the jboss-logging JAR is in my classpath.
Edit: Requested Stack Trace: https://gist.github.com/whargrove/79cbc9c5bd65217e3da3
After restarting Tomcat and re-deploying my WAR the following exceptions are observed in the Tomcat logs:
java.security.AccessControlException: access denied ("java.util.PropertyPermission" "jboss.i18n.generate-proxies" "write")
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'mySessionFactory' defined in ServletContext resource [/WEB-INF/config/spring.xml]: Invocation of init method failed; nested exception is java.lang.NoClassDefFoundError: Could not initialize class org.hibernate.cfg.PropertyContainer
(Full stack trace available in gist link above.)
The message
java.lang.NoClassDefFoundError: Could not initialize class SomeClass
means that the JVM has already tried and failed to perform static initialization on the class SomeClass. There may well be another error which happened earlier on when the JVM tried to load the class the first time.
Taking a look at the source of the PropertyContainer class, the only static intialization is a static initializer that sets a system property, and a line that initializes a logger for the class. Setting a system property will should not cause a problem, so my guess is that the logger class used is missing from your classpath.
The logger class used is org.jboss.logging.Logger. A quick Google for this class suggested a jar named jboss-logging.jar. Try getting a copy of that and adding it to your classpath.
(Incidentally, if you can't find a previous error before the 'Could not initialize class' error, that may well be because the missing JAR affects logging. Logging is something applications tend to assume is always working and can be used everywhere. The exception you are seeing might have been thrown from within a finally block that tried to do some logging when the corresponding try block also tried to do some logging but threw an exception. An exception thrown from within a finally block replaces any exception that had previously been thrown.)
EDIT in response to the stacktrace: I can now see that I was wrong about setting a system property not being the problem! I don't know the first thing about Blackboard Learn, but it is possible that it or something else has tightened up the security in your application and hence caused the above problem.
It does however confirm my belief that the real cause of the problem was before the Could not initialize class message.
I have some tests that load up some Spring context files. When I run the tests from my ant target they work as expected. When I run them from IntelliJ I get a NotWritablePropertyException. I initially figured different classpaths, but the only differences are for IntelliJ's test runner.
Caused by: org.springframework.beans.NotWritablePropertyException: Invalid property 'sessionAcknowledgeMode' of bean class [org.springframework.jms.listener.DefaultMessageListenerContainer]: Bean property 'sessionAcknowledgeMode' is not writable or has an invalid setter method. Does the parameter type of the setter match the return type of the getter?
at org.springframework.beans.BeanWrapperImpl.setPropertyValue(BeanWrapperImpl.java:801)
at org.springframework.beans.BeanWrapperImpl.setPropertyValue(BeanWrapperImpl.java:651)
at org.springframework.beans.AbstractPropertyAccessor.setPropertyValues(AbstractPropertyAccessor.java:78)
at org.springframework.beans.AbstractPropertyAccessor.setPropertyValues(AbstractPropertyAccessor.java:59)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyPropertyValues(AbstractAutowireCapableBeanFactory.java:1276)
... 42 more
It is possible you have some classpath issues. Idea may load resource files in a different way from command line ant call.
The classpaths were not the same. Sorry folks.