I have a problem or possibly I found a bug in Spring Boot. I am not sure at the moment.
I have a project with the following dependencies
spring-boot-starter-thymeleaf
spring-boot-starter-web
spring-boot-starter-actuator
spring-boot-starter-mail
spring-cloud-starter-bus-amqp
spring-cloud-starter-config
spring-cloud-starter-eureka
I want to use a messageSource in my Thymeleaf templates and so I set the following in my application.yml:
spring:
messages:
basename: de/mycompany/messages/message
and placed a message.properties and a message_de.properties in the above package. But the replacing did not work.
So I debugged MessageSourceAutoConfiguration and found, that the #Conditional(ResourceBundleCondition.class) did work. It found my Resources and returned true.
So I let print the debug report and found, that it says
MessageSourceAutoConfiguration
- Bundle found for spring.messages.basename: de/mycompany/messages/message (MessageSourceAutoConfiguration.ResourceBundleCondition)
- #ConditionalOnMissingBean (types: org.springframework.context.MessageSource; SearchStrategy: all) found the following [messageSource] (OnBeanCondition)
So there is another messageSource Bean already defined, but i wondered where it did come from. So i investigated further and found the following log output:
AnnotationConfigEmbeddedWebApplicationContext : Unable to locate MessageSource with name 'messageSource': using default [org.springframework.context.support.DelegatingMessageSource#60df7989]
In fact it comes from the class AbstractApplicationContext in method initMessageSource (around line 622).
There it checks for a bean with name "messageSource" and if it doesn't find one, it creates the above mentioned DelegatingMessageSource.
Am I missing something? Do I have to do something to get the MessageSourceAutoConfiguration happen before this AbstractApplicationContext stuff? Or is this really a bug?
For myself I fixed it by simply creating the messageSource myself as a #Bean, but using the AutoConfiguration would be far smarter :)
Greetings Christian
Turns out this is a bug, hopefully it gets resolved soon, tracked here:
https://github.com/spring-cloud/spring-cloud-commons/issues/29
Related
I tried to upgrade a working application from Spring Boot 2.0.6 to 2.1.2. I had some troubles with tests after this change, but eventually got around that. I can successfully build the application from NetBeans (mvn clean install). However, when I try to run from a command line using mvn spring-boot:run, here is what I get:
APPLICATION FAILED TO START
Description:
The bean 'xxxRepository', defined in null, could not be
registered. A bean with that name has already been defined in null and
overriding is disabled.
Action:
Consider renaming one of the beans or enabling overriding by setting
spring.main.allow-bean-definition-overriding=true
The interesting part is that every time I try to run it, the error is on a different repository, but always with the same message.
It would seem that this has to do with this change:
Bean Overriding
Bean overriding has been disabled by default to prevent a bean being
accidentally overridden. If you are relying on overriding, you will
need to set spring.main.allow-bean-definition-overriding to true.
Given that it is apparently effecting all my repositories, my guess is that there is a configuration problem somewhere. I can follow the recommended action, but it actually made no difference. The problem is that I don't know what to change in the configuration to get this working again. I'm not even sure what to post that is pertinent to the issue. Any ideas on how to figure this out?
We ran into this issue upgrading from Spring Boot 2.0.x to 2.1.x.
I could "solve" this issue by allowing bean definition override with spring.main.allow-bean-definition-overriding: true but it felt like hiding the root cause.
In fact bean definition overriding used to hide poor configuration on our side.
After inspecting our #Configuration classes we were scanning packages containing our repositories twice, using #ComponentScan and #EnableJpaRepository on the same packages from different classes : once with filters #ComponentScan.Filter, once without.
Removing the second component scan fixed the issue.
I have seen this error before and i had a class BOTH annotated with #Component or #Repository or #Service AND also registered as a #Bean in a config class. Is that your case also by any chance?
I got a similar problem, but it was only with #NotNull annotation. When I upgraded the spring it stopped to work. I tried a lot of things that I found here in SO, but the only thing that worked to me was to eliminate the database and run spring again. I know that it sucks, but didn't find another solution.
I am following this example here:- http://www.baeldung.com/spring-graphql
for me the GraphQLSchema bean is not getting autoregistered. it throws me this error:-
No qualifying bean of type 'graphql.schema.GraphQLSchema' available
my Pom file has all requried Spring boot dependecies:-
graphql-spring-boot-starter
graphql-java-tools
graphiql-spring-boot-starter
I have following settings in application.proerties:-
graphql.root=/v1
graphql.servlet.mapping=${graphql.root}/graphql
graphql.servlet.enabled=true
graphql.servlet.corsEnabled=true
Not sure what am I missing, Do I need to explicitly define this bean as on this page:- https://github.com/graphql-java/graphql-spring-boot/blob/master/example/src/main/java/com/embedler/moon/graphql/boot/sample/ApplicationBootConfiguration.java.
But I thought it will autocreate for me, I just need to have *.graphqls on my class path.
I have followed the same tutorial as well and encountered the same error. I ended up figuring out what the issue was and it is that you need to add #Component to the Query class that the tutorial describes.
Once that was done graphiql was finally finding the schema and the /graphql end-point was exposed.
I'm trying to setup a Spring Boot application that uses EclipseLink instead of Hibernate. The project has a similar structure to this example project:
https://github.com/spring-projects/spring-data-examples/blob/master/jpa/eclipselink/src/main/java/example/springdata/jpa/eclipselink/Application.java
The main difference is that our application needs to be packaged as a WAR... so the main Application.java extends SpringBootServletInitializer instead of the JpaBaseConfiguration shown in the example (we have another bean with #Configuration that extends JpaBaseConfiguration).
When the app starts it encounters a ClassNotFoundException for the a naming strategy that comes form Hibernate:
Error creating bean with name 'spring.jpa-org.springframework.boot.autoconfigure.orm.jpa.JpaProperties': Initialization of bean failed; nested exception is java.lang.NoClassDefFoundError: org/hibernate/boot/model/naming/ImplicitNamingStrategy
It seems that this only happens when the application extends from SpringBootServletInitializer.
Turning on debug shows this:
JpaBaseConfiguration.JpaWebConfiguration:
Did not match:
- #ConditionalOnProperty (spring.jpa.open-in-view=true) found different value in property 'open-in-view' (OnPropertyCondition)
Matched:
- #ConditionalOnClass found required class 'org.springframework.web.servlet.config.annotation.WebMvcConfigurer'; #ConditionalOnMissingClass did not find unwanted class (OnClassCondition)
- found ConfigurableWebEnvironment (OnWebApplicationCondition)
Is there any way to exclude the JpaWebConfiguration, but still have the application extend from SpringBootServletInitializer?
UPDATE: After debugging this further I don't believe the JpaWebConfiguration is the issue as that is in the unmatched section of the debug, but something is still causing the creation of a JpaProperties bean and hitting the ClassNotFoundException.
I recently started getting this warning on start up of my Spring Boot application:
o.s.c.a.ConfigurationClassPostProcessor - Cannot enhance
#Configuration bean definition
'beanNamePlaceholderRegistryPostProcessor' since its singleton
instance has been created too early. The typical cause is a non-static
#Bean method with a BeanDefinitionRegistryPostProcessor return type:
Consider declaring such methods as 'static'.
I cannot figure out where it is coming from. I have no such classes ('beanNamePlaceholderRegistryPostProcessor', 'BeanDefinitionRegistryPostProcessor') in my app that I can find so not sure how to prevent this from happening.
Anyone have any ideas?
This question is slightly different to this one as that one seems to be with a class that the user has created.
I finally discovered that beanNamePlaceholderRegistryPostProcessor is part of the Jasypt Spring Boot starter package.
I raised a ticket about it and the author replied immediately, indicating that it is nothing to worry about.
https://github.com/ulisesbocchio/jasypt-spring-boot/issues/45
You can ignore the warning if you want by adding the following to Logback (if you use that):
<logger name="org.springframework.context.annotation.ConfigurationClassPostProcessor" level="ERROR"/>
after Proguard obfuscation i get the following error :
Unexpected exception parsing XML document from ServletContext resource
[/WEB-INF/applicationContext.xml]; nested exception is
java.lang.IllegalStateException: Annotation-specified bean name 'a'
for bean class [com.company.project.b.a.a.a] conflicts with existing,
non-compatible bean definition of same name and class
[com.company.project.a.a]
i'm using annotation based spring configuration , how can i avoid having two classes with the same name using Proguard because Spring doesn't allow two beans to have the same name.
I'm not sure if this is what you want, but you can specify bean name in #Component (and stereotypes #Repository, #Service and #Controller) value:
#Component("myBeanName")
public class MyBean {
}
I had the same problem and nothing else was helping out. Sometimes the problem occurs if you have moved your classes around and it refers to old classes, even if they don't exist.
In this case, just do this :
mvn eclipse:clean
mvn eclipse:eclipse
This worked well for me.
Another cause; you may have different versions of Spring in your classpath, for example, spring 2.x with spring 3.x. In such condition, beans seem to be loaded twice. If you use maven, check if a module does not import an old version of Spring (mvn dependency:tree) and remove it by excluding the involved spring artifact (exclusions).