In my sample spring boot application, i have added a dependency of a custom jar. My sample application has a support for web and jpa.
The jar which i've created contains a Spring MVC controller. Below is the sample code
#Controller
public class StartStopDefaultMessageListenerContainerController {
#Autowired(required=false)
private Map<String, DefaultMessageListenerContainer> messageListeners;
I haven't manually created a bean instance of this controller anywhere in my code.
Problem - When i start my spring boot application by running the main class, i get an error in console that prob while autowiring DefaultMessageListenerContainer.
My question here is, even though this class StartStopDefaultMessageListenerContainerController is just present in the classpath, it's bean shouldn't be created and autowiring should not happen. But spring boot is scanning the class automatically and then it tries to autowire the fields.
Is this the normal behavior of spring and is there anyway i can avoid this?
If the StartStopDefaultMessageListenerContainerController class is part of component scanning by spring container, Yes spring tries to instantiate and resolve all dependencies.
Here your problem is #Autowired on collection. Spring docs says,
Beans that are themselves defined as a collection or map type cannot be injected through #Autowired, because type matching is not properly applicable to them. Use #Resource for such beans, referring to the specific collection or map bean by unique name.
And also Refer inject-empty-map-via-spring
Related
I know what is application Context. It is an interface which provides spring beans.
All beans get initialized in Spring IOC containers.
But How all three are connected. Could you please explain.
Spring beans are the instances of classes that spring manages. You create classes and "mark" them to be spring managed (putting #Component, using #Bean in java configuration and so forth - there are many ways to tell spring that the instance of some particular class should be managed by spring)
When spring starts it creates an application context with is a registry of all beans it resolves.
Spring can inject one bean into another and its the way of spring to instantiate beans.
The principle of "providing dependencies by external container" as opposed to maintaining dependencies by class itself called Inversion of control, and spring implements this concept.
Update 1
There is no such a thing as "spring context" technically speaking
Spring IOC container is a framework that manages the beans (your classes) by means of providing a technical abstraction called application context (its a real interface in java with implementation inside the spring code).
In order to benefit from spring your Beans should have dependencies between them. In this case spring framework that implements IOC principle can "inject" (provide, resolve) dependencies between beans.
Here is an example:
#Component
class A {
}
#Component
class B {
#Autowired
private A a;
}
When spring container instantiates class B (creates the object : new B()) it "understands" that this instance (we call it bean because it's managed by spring) has a "dependency" on class A and since A is also managed by spring, it can "inject" (read put a value) into the property a of class B.
This is called an Inversion of Control. You, as a programmer do not have to instantiate property b by yourself, spring does it for you.
I am developing a sample application that Spring Batch with Spring Boot. My requirement is:
Have my own implementation of BasicBatchConfigurer so that I can configure AsyncTaskExecutor and my own dataSource as I am using SAP HANA as DB for which databaseType is not supported.
I want to use #EnableBatchProcessing(modular=true) so that I can register multiple jobs and launch them with separate Child Context
I have added all the required configurations. Without setting modular=true the Job is Launched and works as expected. It initializes the beans defined from my implementation of BasicBatchConfigurer.
However, once modular=true is set, the beans from my implementation are not initialized.
The code is hosted here: https://github.com/VKJEY/spring-framework-evaluation
I debugged further into the issue:
Looks like, When we set modular=true, BatchConfigurationSelector uses ModularBatchConfiguration
In ModularBatchConfiguration, there's a field Collection<BatchConfigurer> configurers. This has been annotated as #autowired.
I assume that this field is auto initialized if I provided a implementation
of BatchConfigurer as it has been mentioned in the comments of ModularBatchConfiguration class as well
However, While debugging I realized that the above field is still null beacuse of which, It loads DefaultBatchConfigurer and follows the default flow.
My question is why is that field configurers not being initialized in ModularBatchConfiguration? Am I missing something?
I am using Spring boot 2.1.2.
My question is why is that field configurers not being initialized in ModularBatchConfiguration? Am I missing something?
You are hitting a lifecycle issue between Spring Boot custom auto-configuration that you defined in the META-INF/spring.factories file and Spring Batch configuration.
I debugged your code and here is how to fix the issue:
remove org.springframework.boot.autoconfigure.EnableAutoConfiguration=\
com.example.job.data.persistence.config.AsyncBatchConfigurer
from META-INF/spring.factories file. This is not needed as Spring Batch
will detect the AsyncBatchConfigurer when it is declared as a bean.
You can even remove this spring.factories file
remove #ConditionalOnMissingBean(BatchConfigurer.class) from AsyncBatchConfigurer:
Since you declared this class as a #Configuration class, it will also be defined as a bean of type BatchConfigurer and will be detected by ModularBatchConfiguration
With these two changes, the field configurers in ModularBatchConfiguration is correctly autowired with your AsyncBatchConfigurer.
As a side note, you don't need the AsyncBatchConfigurer#configurers method as Spring will do the work of injecting all BatchConfigurer beans in ModularBatchConfiguration.
Hope this helps.
I have created a spring mvc based application but I didn't use this #Configuration annotation. What is the purpose of using #Configuration annotation? By using this, what are we communicating to springMVC container?
Assuming your application is using xml configuration rather than AnnotationConfig so it is not loaded to ApplicationContext at all.
#Configuration is used when ApplicationContext has been initialized and bean registration.
#Configuration annotation is a core Spring annotation, and not Spring MVC. It is a core entry point to configuring Spring-based application using Java config instead of XML config.
Please, use Spring Documentation more often because it is a place where you will find answers to most of your questions. Like this one:
Indicates that a class declares one or more Bean #Bean methods and may
be processed by the Spring container to generate bean definitions and
service requests for those beans at runtime
I am having a little weird behavior with my spring-data-mongo where my repository package is not being scanned by the <mongo:repositories/> tag. I am using spring 3.2.3.RELEASE with spring-data-mongo 1.2.1.RELEASE.
I have a project called edowmis and in it there are 2 maven modules, datalayer and web which a webapp.I am using the datalayer in isolation so the other module can be ignored. I have an application context for datalayer
So I wanted to test my setup by writing a small Unit/Integration test but I've noticed I can't autowire my UserRepository because It says there isn't such a bean
Since I am using IntelliJ I can see certain visuals when things are ok and not ok. I've addec <context:component-scan/> to my application context but no result.
But when I add the #Component annotation it has started identifying the Class.
all information you might need is on pastie.org
Is the #component or #Repository really necessary or something is wrong with my configuration?
Yes, the #Component or #Repository is necessary. The scan simply indicates that spring should look for classes identified via annotations (#Component, #Repository, #Service) and load them as beans. If you don't use repository or component scan, you would have to manually instantiate all spring-managed beans via XML configuration or Java configuration.
You have to tell spring which classes to turn into beans as it doesn't assume everything in the classpath is supposed to be a spring-managed bean, which is why you need to use the annotations.
I have a question about spring and struts.
Currently I have spring injecting my struts action classes for me.
I was experimenting and trying to get Spring to inject my Struts action classes
for me using autowiring.
I have my spring applicationContext config file scanning the base package that the
action class is in using context:component-scan base-package="my.package",
and im using #Component annotation at the action classes class level.
Im also using #Qualifier("myActionClass") at the same action classes class level.
Im not configuring the action class as a Spring bean in applicationContext.
Then in my struts.xml config file, while configuring my action class, instead of giving the fully qualified package and class name, I use the #Qualifier annotation name "myActionClass".
This doesnt work though.
If in my applicationContext config file, configure my action class as a spring bean, get rid of the #Component and #Qualifier annotation on the action class, and in struts.xml, put the action classes Spring bean id for the class, then Spring injects my action class for me and everything is dandy. Only, this isnt using Autowiring the action class, and thats what I was testing.
Anyone know if autowiring using context:component-scan base-package
to scan your packages for your action classes so you dont have to configure them in applicationContext is possible?
Everything is explained in Spring documentation: Apache Struts 1.x and 2.x.
I am not sure whether you are using Struts 1 or 2. For Struts 1 you had to add Spring plugin to Struts configuration (I know it works). In Struts 2 all actions are created by Spring hence they are fully capable of Spring injection like all other beans.
Struts 2 seems to rely on there being a spring bean with the same spring bean-name matching the action class name (full name with package). You can specify the bean name in the #Component annotation, and it's also possible to make a global user-defined bean naming strategy so you can avoid adding this information to all your beans