We have a spring app that works with mongodb.
Now we need it to connect also to mysql.
All the beans are defined in a applicationContext.xml legacy file.
We like that the new mysql configuration will be in java classes.
We created an entity, repository and a configuraion java files.
But it seems that as we try to do so, spring gets confused.
If we try to run the app, it start complaining about the mongo repositories:
Error creating bean with name 'MyMongoRepository': Could not resolve matching constructor (hint: specify index/type/name arguments for simple parameters to avoid type ambiguities
In the intellij we have the "could not autowire" error only on the sql repository (the first 3 are the mongo repositories):
Is it possible that the #configuration class is clashing with the applicationContext?
Should the #configuraion class be in a certain package/folder to work correctly?
Also, in the #configuration file, as there are green beans on the left side, it seems like intellij is able to understand where is the persistence repository.
Thanks for any help.
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"/>
I've got spring application. And recently added Liquibase bean. It's necessary to run it before all beans, including annotated beans like (#Component, #Service etc.). How can I do it without using depends-on.
Thanks a lot!
The options are the same as in Spring: Make sure a particular bean gets initialized first
Depends-on appears to be the standard pattern, but perhaps using the Liquibase ServletListener would work better in your case?
I've just added a custom local plug-in (via 'grails.plugin.location...' build config declaration) to a grails 2.3 project. As soon as I add the plug-in and try to run my application I see a strange behavior whereby all of the beans in my main application suddenly try to eagerload across the board. I.e. if I have:
class FooService {
BarService barService
}
class BarService {
FooService fooService
}
Then the application cannot start. There is no code being executed in FooService or BarService at init time that should cause the Spring context to need to unwrap the either fooService or barService instance but that behavior seems to be happening anyway. In the end the application init fails with an exception like:
Caused by: org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'fooService': org.springframework.beans.factory.FactoryBeanNotInitializedException: FactoryBean is not fully initialized yet
As the fooService requires the barService, which requires the fooService which is still being created.
As soon as I remove the dependency on the custom plug-in then the problem stops. Obviously something either in the plugin or about the plugin (meta data or something) is causing this behavior but I can't figure out what exactly.
Rather than a solution I think what I am looking for here is some trouble-shooting techniques or information leading me to understand why this eagerloading behavior is occurring. I just don't know what the right hooks/configs are that will let me get in the head of the Spring context initialization mechanism.
I found the answer to my question buried deep in the comments of this other SO question: Grails service using a method from another service
Basically my plugin introduced the hibernate plug-in into my project and therefore also introduced transactional-by-default services. This transactional bootstrapping was causing the eager load of all dependencies and thus my circular dependency problem.
The fix was to, at least for now, mark the circularly dependent services as non-transactional. Of course in the future if I need those services to be transactional it seems I will need to re-architect my service setup.
I'm setting up a very small Spring/REST/JPA project with Boot, using annotations.
I'm getting some Bean not found errors in my REST controller class that has an Autowired repository variable, when I move my JPA repository class out to a different package, and calling componentscan on its package. However, everything was working fine when all my files(5 total) were in the same package.
So I was wondering, however unlikely, if the component scan order matters? For example, if a class is AutoWiring some beans from a package that has not been 'component scanned' yet, will that cause a Bean not found error?
No, Spring loads all configuration information, from files and annotations and the environment when appropriate. It then creates beans (instances of classes) according to a dependency tree that it calculates in memory. In order to do this it has to have a good idea of the entire configuration at startup. The whole model derived from all the aggregated configuration information is called the Application Context.
In modern versions of spring the application context is flexible at runtime and so it's not quite the case that all the configuration is necessarily known up front, but the configuration that is flexible is limited in scope and must be planned for carefully.
Maybe you need to share some code. When you move that stuff, you also need to tell Spring where they went. My guess would be you haven't defined #EntityScan and #EnableJpaRepositories (which default to the location of #EnableAutoConfiguration).
There could be several problems:
You moved your class out of the some package where you have #ComponentScan without arguments. That basically means that components are scan only in this package and its children. Thus, moved class are not scanned and there is no bean to wire.
Wrong package name in #ComponentScan args.
The order isn't matter at all. There is an #Order annotation, but it's purpose is more about loading multiple implementations of sth in a different order.
At first Bean Definitions are created and they have nothing to do with wiring. Then via bean post processors, autowired beans are injected. Since there were no bean definition. There is nothing to inject.
In a well structured program it doesn't, because first each bean gets instantiated, then autowired and then you can actually use them.
However there could be situations where the order does matter and I had an issue figuring out what was going on. So this is an example where it would matter:
You have some Repository that you want to fill with data initially, call it SetupData component.
Then you use #PostConstruct to save the default objects.
You have some component that this Repository depends on but isn't managed by Spring, for example a #Converter.
And that #Converter depends on some other component which you would statically inject.
In this case #PostConstruct methods will be executed before the components into your #Converter get autowired which will result in an exception.
Relying on ComponentScan order is a bad habit, because it's not intuitive especially when you are working with multiple people who may not know about. Or there might be such dependencies that you can't fix the code by changing the scan order.
The best solution in this case was using a task executor service that takes care of running initialization functions.