Develop Reference

How to tell if a class is Spring loaded in java?

I have been given a task to assign a property from .properties file to a non Spring bean class using #Value annotation. To do this, I created a method on a #Component annotated class and set the property into it, then called that method from the non Spring bean class. I thought this would work, however, still showing as null.
I was told this is because the #Component annotated class I used is not spring loaded. Question, how can I tell if a class is Spring loaded bean? I have been searching on google but can't find anything helpful aside from examples with #Component or #Configuration annotations. Thanks.

Spring Container is responsible for creating or managing beans. It all satisfy the dependencies by injecting them either through constructor or setter method. But in your case you want the #Value injection in your non spring bean which is really not possible as per my understanding. Because here the spring does not creating the object then how it satisfy the dependencies of it.
You have two options for this situation.
Either annotate class using #Component
Either read property file using Properties
https://www.mkyong.com/java/java-properties-file-examples/

Cannot Autowire interface in spring boot app

I am developing a REST API using spring boot. Following is my package structure
Getting the following exception when I try to start my application
***************************
APPLICATION FAILED TO START
***************************
Description:
Field articleRepository in com.abc.service.ArticleService required a bean of type 'com.abc.dao.ArticleRepository' that could not be found.
Action:
Consider defining a bean of type 'com.abc.dao.ArticleRepository' in your configuration.
Following is my project structure-
com.abc
com.abc.bean
-Article.java
com.abc.controller
-ArticleController.java
com.abc.dao
-ArticleRepository.java (Interface)
com.abc.service
-ArticleService.java
com.abc.web
-AbcApplication.java (main Springboot class)
In AbcApplication.java as it is not in the root package, I have the below annotations
#SpringBootApplication
#ComponentScan(basePackages="com.abc.*")
I tried few ways -
I moved AbcApplication.java to root package com.abc but no success
Instead of interface(ArticleRepository.java) I made it a class, it is working
I keep it as interface but changed annotation from #Repository to #Service/Component still no success.
I am confused how it is working if I change it to class instead of interface.
#Repository
public interface ArticleRepository {
}

You don't have any bean for ArticleRepository. If you will use Spring Data Jpa you have to extend a type of Repository: https://docs.spring.io/spring-data/jpa/docs/current/reference/html/#repositories.
If you will use your own repository, you must implement it.

If you are using any RDBMS and if ArticleRepository repository is responsible for interacting with your database, then you need to either extends CrudRepository or JpaRepository in your ArticleRepository, then only Spring will be able to create the bean of ArticleRepository,and you will be able to autowire your repository.
If you are not extending any of CrudRepository or JpaRepository,then at the time of bean creation,ArticleRepository is only plain java interface and a plain interface can not be instantiated.
And as for your question:
Instead of interface(ArticleRepository.java) I made it a class, it is working
Its because when you declare it as a class, then Spring does instantiate a concrete class, so actual object will be created at the bean creation time and everything will be working as it should be.

Ideally you should have one class that implements interface ArticleRepository . Annotate that class with #Repository, spring will take care of wiring.

I was also encountered with the same issue. What I missed was the spring-boot-starter-jpa dependency. It worked when I added this dependency in the pom.xml file.

MyBatis gives you two samples to access your databases with spring boot.# Component or #Mapper.
Sample link:
mybatis-spring-boot-sample-xml
Suggestion:
Show your ArticleRepository code fully.

interface does not require any annotation (neither #repository not #Service).
If its a DAO file add #Repository annotation to the class implementing the corresponding interface.
And, if its a service then add #Service annotation to the class implementing the corresponding interface.

Order of Configuration in SpringBoot

I am trying to understand how beans that we make using #Configuration tends to override the beans that are generated by SpringBoot by default. I have been working on a project where in many cases we create beans for things like ZuulConfigs and the assumption is, whatever we are making shall take precedence over the default generated bean. I have been trying to figure this out but can't. Basically,
Is Spring achieving this via some custom class loader
If not how is this precedence working. Can I give some precedence in similar manner to my beans
Can I generate similar hierarchy in my project,if so how
The help is highly appreciated

Spring AutoConfiguration is used to provide a basic configuration if certain classes are in the classpath or not.
If you want to configure the order in which beans are instantiated by spring you can use
#DependsOn("A")
public class B {
...
}
This would create bean "A", then "B". Hence you can order the configuration depending upon the beans need first to be done. Anyways Spring automatically detects the dependencies by analyzing the bean classes.
for more help check this question
Spring Boot AutoConfiguration Order
Alternative :
There is also "#AutoConfigureOrder" annotation(where you can prioritise the configuration), you can have a look in the code for deeper understanding.
Documentation of AutoConfiguration is here

First of all, class loading and bean creation are two different things. We don't need to create a bean to load a class, however, a class has to be loaded in order to create a bean.
Now, coming back to Spring's example, Spring looks into all the packages configured by #componentScan and creates beans of all the classes annotated with #Bean, #Configuration and/or #Component. Spring's container keeps track of all the beans created and hence, when it encounters user defined bean with same name and class type as default bean, it replaces the original definition with user defined one (e.g. we can create our custom #ObjectMapper to override Spring boot's own instance). You can also use #Primary annotation to make you bean take precedence if another definition with same class exists (documentation here).
Below are the answers for your questions:
Spring uses reflection to load the classes and create instances. Although you can load the classes with your custom class loader (more on that here), you don't need to worry about it for #Configuration.
Yes, you can use #Primary annotation to give your bean a precedence. You can also use #Order(here) to define the creation order for your beans.
With #Primary, #Order and #Qualifier annotation you can define your own hierarchy for bean creation.

Can I give some precedence in similar manner to my beans
Yes.
A) To define a specific order your Configuration classes will be handled (by the way, a Configuration class does not have to be annotated with #Configuration (so-called full definition), but it's enough to be annotated with #Component, #ComponentScan, #Import, #ImportResource or just have a method annotated with #Bean - so-called lite definition), you should
1) add your Configuration Candidates to your SpringApplication's primarySource, for example, in your main method like that
SpringApplication.run(
new Class[]{YourSpringBootApplication.class, Config1.class, Config2.class, ...},
args);
2) and annotate each of your Configuration Candidates with #Order annotation, any other ordering means like Ordered interface, #DependsOn etc will be ignored by ConfigurationClassPostProcessor, the order in the primarySource array will also be ignored.
Then ConfigurationClassPostProcessor will sort your Configuration Candidates and handle them according the #Order annotation value you specified.
B) The precedence can also be achieved by defining your own AutoConfiguration classes. Although both Configuration and AutoConfiguration are handled by the same ConfigurationClassPostProcessor, they are essentially distinctive machineries. To do so
1) define in your classpath /META-INF/spring.factories file and put in the EnableAutoConfiguration section of it your AutoConfiguration classes like that
org.springframework.boot.autoconfigure.EnableAutoConfiguration=\
your.package.AutoConfig1,your.package.AutoConfig2
2) and annotate your AutoConfiguration classes with #AutoConfigureOrder, #AutoConfigureAfter, or #AutoConfigureAfter annotations, any other ordering means again will be ignored.
Like #Strelok pointed out, AutoConfiguration classes, your own and provided e.g. by spring-boot-autoconfigure library alike, will be added to the end of the list of Configuration Candidates.
Remember, however, that the order the Configuration Candidates will be handled by ConfigurationClassPostProcessor does not necessarily coincide with the order the beans defined by the Configuration classes will be created. For example, you might define your Configuration class that overrides TomcatServletWebServerFactory to make your own customization of Tomcat web server like
#Configuration
public class EmbeddedTomcatConfig {
#Bean
public TomcatServletWebServerFactory containerFactory() {
...
return customizedTomcatWebServerFactory;
}
but this method will be called right at the moment when your Spring Boot application decides to create a Web server, regardless of how you defined the precedence for your EmbeddedTomcatConfig Configuration class.
Is Spring achieving this via some custom class loader
There is no need to. Although you could, as always with Spring, define your own ClassLoader for BeanFactory, standard ClassLoader is good enough if everything you need for Configuration in your application is available in the classpath. Please notice, that at first phase ConfigurationClassPostProcessor does not load (i.e. does not resolve) the Configuration candidates classes (otherwise, most of the classes in spring-boot-autoconfigure library will fail to load). Instead it analyzes their annotations with bytecode analyzer, ASM by default. For that purpose, it is just enough to get a binary form, a byte array, of a class to feed it to bytecode analyzer.

Just know this: Spring Boot (specifically) auto configuration classes are always configured last. After all user beans have been created. Spring Boot auto configuration classes almost always use the #ConditionalXXXX annotations to make sure that any beans of the same type/name and other conditions that are configured in your application will take precedence over the Spring Boot auto-configured beans.

If you want your #Component to take precedence over other #Component while scanning all the components by spring, use #Order(Ordered.LOWEST_PRECEDENCE) i.e. the max value to load your component over other.
#Primary is used to give your bean a default preference, we can override the default preference using #Qualifier

What will happen if we interchange #service and #repository annotation in the spring MVC

Why we needs to use #service inside the service Implementation and #repository in the DAO Implementation. There are no problem occur when I interchange the #service and #repository annotation in the spring MVC.

According to documentaion #Repository,#Service,#Controller are all synonyms. They all are just specializations of #Component annotation. So, generally, they can be used one instead of other. But ... you should not do this.
First reason: any of these annotations make clear the role of your component in the application. Shows - is this component belongs to the controller, service, or data layer.
Second reason: some of these annotations processed differently by different Spring modules. For example, Spring Data JPA will process #Repository and will try to replace with implementation any interface marked by this annotation. Spring also will apply automatic exception translation to such classes. Another example: Spring Web MVC processes #Controller, and uses classes marked with it in URL mappings.
Actually, in future versions, some modules of Spring could process #Service in a particular way. Not as simple #Component. That's why documentation advises:
It is also possible that #Repository, #Service, and #Controller may
carry additional semantics in future releases of the Spring Framework.
Thus, if you are choosing between using #Component or #Service for
your service layer, #Service is clearly the better choice.

It depends on what you use for the remainder of the framework. In theory nothing changes as the #Service and #Repository annotations are basically #Component annotations. The same could be said for #Controller or #Endpoint (for Spring Ws and there are more).
However they express an intent of what a class is (a service, a repository) and makes it clear to the user to what layer that class belongs.
However if you also use Spring for transaction managemnt then #Repository is also a trigger for adding exception translation to that class (also see the reference guide).
Although nothing has to break it probably will at some point.

Some doubts about the use of **#Autowired** annotation and interface declaration in Spring Framework

I am quite new in Spring framework and I have some questions about the use of #Autowired annotation and interface declaration.
Referring to this example:
http://viralpatel.net/blogs/spring3-mvc-hibernate-maven-tutorial-eclipse-example/
I know that #Autowired annotation can be used to automatically link a bean on a property.
In the previous example I have the following situation:
I have a ContactDAO interface and it's implementation class named ContactDAOImpl
Next in the class ContactServiceImpl there is this variable annoted using #Autowired:
#Autowired
private ContactDAO contactDAO;
My first doubt is related to the fact that ContactDAO is an interface so what am I wiring? The concrete type: ContactDAOImpl ? If yes, is the Spring Framework that do it?
The second doubt is related to the fact that in the spring-servlet.xml configuration file there is not a bean definizion for the ContactDAO orf ContactAOImpl class...why? Is it because ContactDAOImpl class is annoted using #Repository annotation?
Thanks
Andrea

My first doubt is related to the fact that ContactDAO is an interface
so what am I wiring? The concrete type: ContactDAOImpl ? If yes, is
the Spring Framework that do it?
Spring will autowire an implementation of the interface for you, as long as there's only one matching implementation. There's also a way to match a single implementation from multiple candidates to your autowiring by using #Qualifier with #Autowired and naming the implementation.
The second doubt is related to the fact that in the spring-servlet.xml
configuration file there is not a bean definizion for the ContactDAO
orf ContactAOImpl class...why? Is it because ContactDAOImpl class is
annoted using #Repository annotation?
If you're using annotations (#Component, #Repository, #Service, #Controller) in your implementations for configuration, you don't need to explicitly define the bean in the xml (although you can do that also).
Edit: this old answer of mine might shed some more light about using annotations in Spring.

The answers to your two questions are Yes, and Yes.
In fact, you might not have an instance of ContactDAOImpl autowired in the service, but an instance of a proxy, which deletages to an instance of ContactDAOImpl. The proxy will typically handle transactions, translate exceptions, etc.
And the #Repository annotation is an alternative (simpler) way to declare a Spring bean. It works only if you have an element in the Spring xml file telling it to discover annotated beans.

Spring will autoscan all your classes and find all annotated classes and register them, this in your spring config will tell it to do that:
<context:component-scan base-package="my.base.package" />
Therefore you do not need to declare your #Repository in your configuration file.
Onto the first part of your question, this is the unpinning of the IOC pattern; your Service class is only aware of the interface of the DAO, this means that it is not dependent on the implementation.
During scanning Spring will find all of your annotated classes and when you ask for an #Autowired then it will attempt to find a class that your have annotated that is an implentor of the interface you have asked to have Autowired.
Have a look at the Spring documentation on Annotation Configuration.