This question might be trivial but still i'm unable to find a good reason or best practice towards #ComponentScan in Spring
DI works just by self annotating the class then why do we need #ComponentScan
What is the best practice towards this?
#ComponentScan tells Spring in which packages you have annotated classes which should be managed by Spring.
Spring needs to know which packages contain spring beans, otherwise you would have to register each bean individually in(xml file). This is the use of #ComponentScan.
Take a simple example, you have a class and annotated with #Controller in a package package com.abc.xyz; , you have to tell the spring to scan this package for Controller class, if spring didn't scan this package, then spring will not identifies it as a controller class.
Suppose if your dealing with configuration file,
<context:component-scan base-package="com.abc.xyz">
like this,
When spring loads the xml file, this tag will search the all the classes present in the package com.abc.xyz, so any of the class containing #controller, #Repository #Service etc.., if it found then spring will register these annotated class in the bean factory.
Suppose if your using spring boot application,
Then your spring-boot application is annotated with The#SpringBootApplication.
#SpringBootApplication annotation is equivalent to using #Configuration, #EnableAutoConfiguration and #ComponentScan with their default attributes.
One more point if you didn;t specify the base package name in #ComponentScan,
it will scan from the package, where the #Springbootapplication present
Related
My #SpringBootApplication annotation is present in com.abc.def package.
According to this article , using #SpringBootApplication annotation is equivalent to using #Configuration, #EnableAutoConfiguration, and #ComponentScan with their default attributes :-
https://docs.spring.io/spring-boot/docs/2.0.x/reference/html/using-boot-using-springbootapplication-annotation.html
If i supply my own #ComponentScan, does it add new packages to the default value or completely override the default ?
#SpringBootApplication annotation can component scan classes from packages under Application class belong to . Also you can add #ComponentScan to scan classes not under package Application class belongs to.
#ComponentScan("external.pkg")
#SpringBootApplication
class MyApp{
}
the annotation #SpringBootApplication contains #EnableAutoConfiguration annotation, which will scan through your jar, class, and maven dependencies in the classpath to register beans. If you declare beans cross packages and only want to use specific beans from specific packages, then use #ComponentScan
#ComponentScan gives you a fine-grained package or class level control on what beans you declared would be registered.
The #SpringBootApplication annotation doesn't allow all the filter customizations supported by #ComponentScan. We observed in our application that spring boot was automatically loading a #Configuration class from a library outside the package hierarchy of the class annotated with #SpringBootApplication.
If you want more control, one idea is to omit the #SpringBootApplication annotation and just specify the individual annotations #Configuration, #EnableAutoConfiguration, and #ComponentScan with your desired customizations.
More information is available in Spring Boot's Documentation:
18. Using the #SpringBootApplication Annotation
Good luck
I recently started exploring Spring Boot. I see that there are 2 ways to define Beans in Spring Boot.
Define #Bean in the class annotated with #SprinBootApplication
Define #Bean in a class annotated with #Configuration
I am also confused about stereo-type annotation #Repository #Service #Controller etc.
Can someone please explain how dependency-injection works with these annotations?
Yes it is possible.
Either you use #Bean in any of your #Configuration or #SpringBootApplication class or mark the bean classes explicitly with annotations like #Service, #Component #Repository etc.
#Service or #Component
When you mark a class with #Service or #Compoenent and if spring's annotation scanning scope allows it to reach to the package, spring will register the instances of those classes as spring beans.
You can provide the packages to be included/excluded during scan with #ComponentScan
#Bean
#Beans are marked on factory methods which can create an instance of a particular class.
#Bean
public Account getAccount(){
return new DailyAccount();
}
Now in you application you can simply #Autowire Account and spring will internally call its factory method getAccount, which in turn returns an instance of DailyAccount.
There is a simple difference of using #Bean vs #Service or #Compoenent.
The first one makes your beans loosely coupled to each other.
In the #Bean, you have flexibility to change the account implementation without even changing any of the account classes.
Consider if your classes instantiation is a multi-step operation like read properties values etc then you can easily do it in your #Bean method.
#Bean also helps if you don't have source code access to the class you are trying to instantiate.
Spring Boot auto-configuration attempts to automatically configure your Spring application based on the jar dependencies that you have added.
You need to opt-in to auto-configuration by adding the #EnableAutoConfiguration or #SpringBootApplication annotations to one of your #Configuration classes.
You are free to use any of the standard Spring Framework techniques to define your beans and their injected dependencies. For simplicity, we often find that using #ComponentScan (to find your beans) and using #Autowired (to do constructor injection) works well.
One way is to define #Bean in the class annotated with
#SprinBootApplication
If you see #SprinBootApplication it is combination of many annotation, and one of them is #Configuration. So when you define #Bean in the Main class, it means it's inside #Configuration class.
According to Configuration docs :
Indicates that a class declares one or more #Bean methods and may be
processed by the Spring container to generate bean definitions and
service requests for those beans at runtime.
class annotated with #Configuration
When you define #Bean is a class annotated with #Configuration class, it means it is the part of spring configuration all the Beans define in it all available for Dependency-Injection.
I have also seen some code where neither of the 2 above approaches
have been used and yet dependency injection works fine. I have tried
to research a lot on this but could not find any concrete answer to
this. Is this possible?
I am assuming you are talking about Sterio-type annotation. Every sterio type annotation has #Component, according to docs :
Indicates that an annotated class is a "component". Such classes are
considered as candidates for auto-detection when using
annotation-based configuration and classpath scanning.
I seems have problem understanding these 2 annotation. I have try to read the javadocs but still cannot figure out. Can anyone help to explain with simple code about these 2 ?
Thank so much in advance.
You use #Configuration as a replacement to the XML based configuration for configuring spring beans. So instead of an xml file we write a class and annotate that with #Configuration and define the beans in it using #Bean annotation on the methods.
And finally you use AnnotationConfigApplicationContext to register this #Configuration class and thus spring manages the beans defined. Small example you can find at Spring Configuration Documentaion.
Quoting from the above link
It is just another way of configuration Indicates that a class declares
one or more #Bean methods and may be processed by the Spring container
to generate bean definitions and service requests for those beans at
runtime.
And #Configurable is an annotation that injects dependencies into objects that are not managed by Spring using aspectj libraries. i.e., you still use old way of instantiation with plain new operator to create objects but the spring will take care of injecting the dependencies into that object automatically for you.
#Configuration is the heart of the Java-based configuration mechanism and provides an alternative to XML-based configuration.
#Configuration classes are just like regular #Components classes, except that methods annotated with #Bean are used to factory beans.
Spring Boot's support for Spring data configuration is generally by org.springframework.boot.autoconfigure.data.AbstractRepositoryConfigurationSourceSupport, and this class use the follow code to determine what packages to scan for repositories:
AutoConfigurationPackages.get(this.beanFactory)
So, basically Spring Data with Spring Boot only scan the package which contains the #EnableAutoConfiguration or #ImportAutoConfiguration, but not consider the #ComponentScan, Is this correct ?
The #ComponentScan annotation is a core Spring Framework feature to search for classes annotated with #Component. Since Spring Data repositories are interfaces (and not annotated), the #ComponentScan annotation won't pick them up.
If you are using Spring Data outside of Spring Boot, you can scan for Spring Data repositories using #EnableJpaRepositories with the basePackages attribute set.
When it comes to Spring Boot, there's usually no need to use either #ComponentScan or #EnableJpaRepositories. If you structure your code as suggested, both components and repositories will be picked up.
To get back to your original question about AbstractRepositoryConfigurationSourceSupport. If you look at the source of #SpringBootApplication you'll see it's annotated with #ComponentScan (to find #Components) and #AutoConfigurationPackage (via #EnableAutoConfiguration). The #AutoConfigurationPackage sets up AutoConfigurationPackages with the value that's later retrieved.
If you want to override the packages the Spring Data searches for repositories (for example in tests) you'll need to use #EnableJpaRepositories to completely override auto-configuration. I usually don't do this, but instead use #DataJpaTest and pick up my main configuration.
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.