Is there a spring property to lazy-init all beans that spring framework loads ?
I know about these properties
- lazy-init="true"
- default-lazy-init="true"
however there are multiple spring config xml files and some are packaged within jar so dont have liberty to change neither <bean> nor <beans> tag.
Any other way to tackle this via configuration ? or programatically ?
Short of extending the Spring bean loader, none that I know of.
You caN also use #Lazy annotation, but it is the same as you mentioned above.
According to java doc this should work ( though it looks not nice)
if (context.getBeanFactory() instanceof DefaultListableBeanFactory)
{
((DefaultListableBeanFactory) context.getBeanFactory()).setAllowEagerClassLoading(false);
}
I've implemented this on my company, had to extend some classes of spring tough. It wasn't easy, but we gained about 20s on every tomcat startup. Unfortunately, for privacy clauses, I can't show the code, but take a look at ClassPathBeanDefinitionScanner,DefaultBeanDefinitionDocumentReader,ContextNamespaceHandler and ComponentScanBeanDefinitionParser classes.
Starting with Spring Boot 2 you can use the spring.main.lazy-initialization property to configure lazy initialization across the whole application.
Setting the property value to true means that all the beans in the application will use lazy initialization.
in application.yaml
spring:
main:
lazy-initialization: true
or in application.properties
spring.main.lazy-initialization=true
Related
From documentation Spring Boot uses ConcurrentMapCacheManager as CacheManager implementation by default if we don't define own CacheManager bean definition. But I keep getting 'No qualifying bean of type 'org.springframework.cache.CacheManager' available' error eventhough spring-boot-starter-cache and #EnableCaching is there.
Any help would be greatly appreciated.
Best regards,
SetNug
Short answer... NO.
I suspect you are having problems while (integration) testing? If so, then you probably need to declare the appropriate "test slice annotation", that is #AutoConfigureCache; see Javadoc.
To demonstrate, I created a simple example with a test class contained in this module of my SO repository. You must declare the #AutoConfigureCache annotation in configuration (see here) even if your test is a #SpringBootTest.
As Spring Boot's documentation describes, all of Spring Boot's auto-configuration (which is quite extensive) can be a bit much for testing. As such, none of Spring Boot's auto-configuration is enabled by default. Therefore, you must explicitly enable what you want, or, alternatively, you can declare that you want Spring Boot's entire auto-configuration enabled, by replacing the #AutoConfigureCache annotation declaration with Spring Boot's #EnableAutoConfiguration annotation instead.
You are correct that Spring Boot will auto-configure a "Simple" caching provider (i.e. the ConcurrentMapCacheManager, or in other words, a Spring CacheManager implementation backed by a java.util.concurent.ConcurrentHashMap; see here) when no other cache provider implementation (e.g Redis) is present or explicitly declared.
However, Spring Boot auto-configuration is only in effect when your Spring Boot application is an "application", which I have shown here.
Of course, it is also true that if your #SpringBootApplication annotated class is found (in the classpath component-scan) by your test as described, then it will also enable caching without any explicit annotations, such as, no need to explicitly declare the #AutoConfigureCache test slice annotation, even.
NOTE: In my example, I deliberately did not package the source according to the suggested structure. So, if I were to replace the #AutoConfigureCache annotation declaration in my test configuration with #Import(SpringBootDefaultCachingApplication.class) and comment out this assertion from the application class, then the test would also pass. Using the #Import annotation in this way works similarly as if the test class and application class were in the same package, or the application class were in a parent package relative to the test class.
1 last tip... you can always enable Spring Boot debugging (see Baeldung's blog) to see what auto-configuration is applied while running your application, or even while running tests.
I have a Spring Boot application with different submodules which also contains spring components.
And in the main web modules I use 70% of the beans from the submodules. It depends on the application.yml properties, if the property group (which points to a bean) is enabled or not.
First I wanted to create Aspect-s, so when a method of a bean (which is not enabled by it's property) is called, then throw an exception. This solution could work, but then I would need to create Aspect classes, method annotations, import more and more dependencies.
So I am just wondering, would be there any other easier solution to disable a bean, or do not load at all to the spring boot container?
I would imagine something like #DependsOn, but for this you need to give a name of a bean name, but you cannot use this annotation to work with yml property.
Other easy solution is to #Bean or #Import every bean I want to managed by spring container, instead of #Import everything once from submodules, but then it is a static setting, cannot be overwrite by a single property from yml.
Spring introduced the concept of conditionals quite some time ago. Spring Boot uses this to a great extend to conditionally enable features. It even created a lot of conditional rules which you can use.
One of those rules is the conditional on a property rule. To use this rule add an #ConditionalOnProperty annotation to your bean. Now it will only be included if said property is enabled or has the specific value.
#ConditionalOnProperty(name="your.property.name")
Is it possible to have a Spring application with both Spring XML that defines some of the beans and also a #Configuration class that defines other beans?
Yes, it's possible.
Spring Boot and Spring 5.x will drive you away from XML and towards annotations. It's a good idea to follow the trend and write using the proper idiom.
None of my Spring Boot apps use XML. That was part of Rod Johnson's original vision for Interface 21/Spring, but annotations have won the day.
It is certainly possible, but it is not recommended. Bean configuration should be consistent to be either all in #Annotations or in XML files.
Is there any specific reason that you want to put some bean configuration in XML rather than in #Configuration class?
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?
In struts2 i almost did not use any xml configs and used much of annotations for MVC. I build a small application in that way using struts2. Now i want to develop same project using spring 3.2. Now i want to use annotation to create beans and request mapping (this i used). I want a clear example of using bean annotations and is it possible to set properties using annotations. I am getting confused because the documentation is too large, and many annotations. providing a simple list of annotations and their usage with simple example will be a great help.
Iam doing sample project on Spring 3.1.
I have used some annotations to create beans.Below are the annotations i have used.
#Component - Annotation used to create a bean given by Spring
#Resource,#Bean
JSR Annotations: #Controller,#Repository, #Service
If you are annotating your class with above annotations Spring Container will create beans for you.
Your properties will be set with help of #Autowired annotation.