public class Person {

Car car;
public void setCar(Car car) {
this.car = car;
}
Public void start()
{
Car.move();

public class Car {

public void move()
{
System.out.println("Car Moving");
}

<?xml version="1.0" encoding="UTF-8"?>

<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:context="http://www.springframework.org/schema/context"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context-3.0.xsd">

<bean id = "person" class ="Person">

<property name="car" ref="car"/>
</bean>
<bean id="car" class="Car"/>
</beans>

Autowiring is of 4 types
1) byName
2) byType
3) constructor
4) autodetect

1) byName

The name of the attribute in the Person class should be same as the bean id/name inside the spring
configuration file.

Person class and dependent classes are same as above, We need to change only in spring configuration
file

Copy this code

<?xml version="1.0" encoding="UTF-8"?>

<beans xmlns="http://www.springframework.org/schema/beans"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:context="http://www.springframework.org/schema/context"

xsi:schemaLocation="http://www.springframework.org/schema/beans

http://www.springframework.org/schema/beans/spring-beans-3.0.xsd

http://www.springframework.org/schema/context

http://www.springframework.org/schema/context/spring-context-3.0.xsd">

<bean id = "person" class ="com.kb.autowiring1.Person" autowire="byName">

</bean>

<bean id="car" class="com.kb.autowiring1.Car"/>

<bean id="add" class="com.kb.autowiring1.Address"/>

</beans>

2)byType

The data type of the attribute should be same as the data type of the bean defined in the spring
configuration file.

So in our case,Person has car attribute and its datatype is “Car”.

If you use byType of autowiring then spring looks for the “Car” type bean inside spring configuration file.

So beans config file should have below entry

Copy this code

<bean id = "person" class ="com.kb.autowiring1.Person" autowire="byType">

</bean>

<bean id="car" class="com.kb.autowiring1.Car"/>

</beans>

Note:If we have many beans for the same datatype then we will get an error.

3)constructor

In this method , spring searches for the type of constructor argument inside spring config file

Person class has below constructor

Copy this code

public class Person {

Car car;

public Person(Car car) {

this.car=car;

System.out.println("person");

autowiring is done as below

Copy this code

<bean id = "person" class ="com.kb.autowiring1.Person" autowire="constructor">

</bean>

<bean id="car" class="com.kb.autowiring1.Car"/>

</beans>

4)autodetect or default

If we choose Autowiring type is autodetect/default then Autowire by constructor first , if not then
autowire by Type.

If we use this way of autowiring then it will do automatic autowiring of 2 methods

1) autowire by constructor, if matching constructor is found

2) autowire by type, if no matching constructor is found then.

<bean id = "person" class ="com.kb.autowiring1.Person" autowire="autodetect">

</bean>

<bean id="car" class="com.kb.autowiring1.Car"/>

</beans>

Or

Copy this code

<bean id = "person" class ="com.kb.autowiring1.Person" autowire="default">

</bean>

<bean id="car" class="com.kb.autowiring1.Car"/>

</beans>

Autowiring all beans by ‘single tag’ in configuration file

If we want to autowire all the beans in the config file by one of the above 4 types, then we can achieve
this by using default-autowire=” “ element in beans tag which will apply it for all the beans rather than
specifying autowire strategy for each bean.

Look at the below example how we do it

Copy this code

<?xml version="1.0"encoding="UTF-8"?>

<beans xmlns="http://www.springframework.org/schema/beans"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-3.0.xsd"

default-autowire="byType">

<bean id="somebean1" class="some class 1"/>

<bean id="somebean2" class="some class 2"/>

<bean id="somebean3" class="some class 3"/>

</beans>

Now all the 3 beans defined inside beans tag are having autowire feature enabled and it is byType as
specified in beans tag.

The <context:annotation-config> annotation is mainly used to activate the dependency

injection annotations. @Autowired, @Qualifier, @PostConstruct, @PreDestroy,
and @Resource are some of the ones that <context:annotation-config> can resolve.

Bean Definitions

As we all know, Spring provides us with two ways to define our beans and
dependencies: XML configuration and Java annotations. We can also categorize Spring’s
annotations under two groups: dependency injection annotations and bean annotations.
Prior to annotations, we had to manually define all our beans and dependencies in XML
configuration files. Now thanks to Spring’s annotations, it can automatically discover and
wire all our beans and dependencies for us. So, we can at least eliminate the XML
needed for beans and dependencies.
However, we should remember that annotations are useless unless we activate them. In
order to activate them, we can add either <context:annotation-
config> or <context:component-scan> on top of our XML file.
In this section, we’ll see how <context:annotation-config> and <context:component-
scan> differ from each other in terms of their ways of activating annotations.

As similar to <context:annotation-config>, <context:component-scan> can recognize and

process the dependency injection annotations too. Moreover, <context:component-
scan> recognizes bean annotations that <context:annotation-config> doesn’t detect.
Basically, <context:component-scan> detects the annotations by package scanning.
To put it differently, it tells Spring which packages need to be scanned to look for the
annotated beans or components.
@Component, @Repository, @Service, @Controller, @RestController,
and @Configuration are several ones that <context:component-scan> can detect.

Field-based dependency injection drawbacks

Disallows immutable field declaration

Field-based dependency injection won’t work on fields that are declared

final/immutable as this fields must be instantiated at class instantiation. The only
way to declare immutable dependencies is by using constructor-based dependency
injection.

Lack of Visibility and Control

Field injection hides beans within the class, making them less visible to other developers and
complicating the understanding of a class’s dependencies. With field injection, it becomes harder to
determine which beans are required. This leads to increased time analyzing the code. This lack of
visibility can lead to confusion, especially when working on larger codebases or working with other
developers.

Difficulty in Testing
Field injection makes unit testing more complex. Since you are assigning beans directly to fields, it
becomes difficult to inject mock objects or stubs during testing. The ability to test code thoroughly is
crucial, and field injection can hinder the ability to isolate dependencies and create meaningful test
cases.

Increased Coupling

Field injection tightly couples classes to their dependencies. When you assign beans directly to fields,
it hurts the loose coupling of the application. With field injection, the class becomes directly
dependent on the specific implementation of the dependency, making it harder to swap or change
beans without changing the class itself.
Nullability and Order of Initialization

Field injection expects all beans it requires to be already available. However, this assumption can lead
to null pointer errors. Additionally, when dependencies are cyclic, the order of bean creation
becomes crucial, bringing potential bugs and unexpected behavior.