Spring Framework And Dependency Injection For Beginners

In Module I, which is this book, we’ll first learn how to create a new Spring project and code some "hello, world" stuff. Then we’ll explore Spring’s dependency injection concepts and its commonly used real-world dependency injection features — like profiles, application properties, conditional annotations etc. — using Java configuration rather than XML. Even if you don’t take the full course, this module is an independent course in itself that you can go through before taking any other Spring course.

In Module II, we’ll learn the concepts and useful real-world features of Spring MVC.

In Module III, we’ll dive into the commonly used Spring projects such as Spring Security, Spring Data, Spring AoP, and also some advanced Spring MVC stuff such as custom validation, validation groups and exception handling. We’ll also walk through coding a real-world user module having features like signup, login, verify email, forgot password, display and edit user profile. In fact, when developing a new Spring application, you can fork our source code and build upon that.

Being in the era of services and microservices rather than full-stack applications, in Module IV, we’ll learn how to develop real-world REST services using Spring and its latest best practices. In fact, we’ll go through a complete blueprint having many advanced features, such as social sign-on (using multiple providers like Google and Facebook), captcha validation, stateless API key authentication, cross-cutting validation and exception handling, etc.. That blueprint also includes a robust user module, and is actually packaged as a configurable and extensible open source library, named Spring Lemon. You can include that in your projects and, with some configuration, start coding your business logic straightaway.

To know more about the full course and the content, visit our landing page.

To follow this book, you should already be knowing core Java and its object oriented features like classes and interfaces. Knowledge of web development will help but isn’t mandatory.

To follow the practical steps, you also should have JDK 8 and some IDE installed. We’ve used Oracle JDK 8 and Spring Tool Suite on a Windows 10 machine.

This book ia a step-by-step walkthrough, accompanied with source code available at GitHub. The code is tagged by lessons, and we’ll provide you the link to the exact tag below each lesson. Even if you are new to Git, you can find a downloadable zip by following that link.

Because Spring projects are standard Java projects, you can just create those manually. In fact, the Spring guides like this one show how to do it that way. We won’t recommend it though — there are easier ways available.

For easily creating new projects, Spring comes with an Initializr wizard available at start.spring.io. You can feed your project metadata there and download a zip file, which you can unzip and import in your IDE.

IDEs go one step further. For example, Spring Tool Suite provides a Spring Starter Project wizard, available as shown below:

If you have IntellijIDEA, you’ll find a wizard at File → New → Project, looking as below:

These wizards in fact use the same start.spring.io service under the hood, and ask for the same set of metadata.

So, ready to take off? Open your IDE, and follow me.

Whether you use start.spring.io or an IDE, you’ll need to provide the following metadata.

Click here to browse and download the source code so far.

If you know Git, looking at the above URL you’ll have figured out that the project is hosted at GitHub, with tags corresponding to the topics of this book. For example, new-project is the tag name for the source code so far.

Browsing the source code of the generated project will tell you that it’s just a java application, with the standard maven layout:

Let’s give a look inside it.

Let’s now see the application running!

In STS, using the Boot Dashboard is the best way to run Spring Boot applications. If it’s not visible, open it by clicking on the icon shown below:

The dashboard looks like this:

As shown above, first select the application there, and then click on the debug (or run) button to run it.

But running the application doesn’t do anything except just writing a few lines to the console. To see some action, let’s code a controller class and a request handler method in that. These terms look like alians? Don’t worry, you don’t need to know about these now. Just carry on.

So, create a new package inside the root package, say controllers, and create a new class in that, say HelloController.

Then, code HelloController as below:

Now, press the Debug button on the Boot Dashboard to rerun the application. Then visit http://localhost:8080/hello on a browser, and you’ll see "Hello, world!"

But how does this work? Not yet the rigt time to discuss about that. Instead, next section onwards, we’ll explore Spring’s DI features.

So, let’s code an interface, named MailSender, and a couple of its implementations, named SmtpMailSender and MockMailSender. SmtpMailSender will be used for sending SMTP mails, whereas MockMailSender will just write the mail content to the console.

Let’s start by creating a new package in the root package, say mail, and then create the following:

As you see, the send method above takes three parameters:

Time to code the implementations:

As you see, MockMailSender just writes the mail onto the log.

"What? SmtpMailSender as well just writes to the log?"

Yes, it’ll eventually send actual SMTP mails, but for now let it be simple. Notice that currently the only difference between it and the MockMailSender is the word SMTP in line 13.

For testing the service, let’s now code a MailController class in the controllers package, as below:

As you see above, the instance variable mailSender is instantiated with a new MockMailSender. It’s then used in the request handler method to send the mail.

If you now run the application and visit http://localhost:8080/mail, you’ll see “Mail sent” in the browser, and the log lines on the console.

In MailController, we’ve instantiated a MailSender like this:

Referring to the concrete class MockMailSender above tightly couples it to MailController. In other words, MailController is now depending on MockMailSender. That means, if we ever change our mind to use SmtpMailSender instead of MockMailSender, we’ll need to alter the source code.

This kind of tight coupling with concrete classes is evil. It won’t let us switch the implementations easily. For example, we now can’t use MockMailSender in development environment whereas SmtpMailSender in production.

This is where dependency injection comes in. Let’s see how to do it in Spring.

Using dependency injection of Spring, here is a solution to the above problem:

Run the application now and visit http://localhost:8080/mail, and you see it working!

So, when developing a Spring application, you basically have to know two things:

There are multiple ways to do these – Spring’s DI is very rich. Next section onwards, we are going to go more deep into these.

@Autowired can be applied not only on fields — as we did in the last section — but also on instance methods and constructors. See the examples below:

When @Autowired is applied on instance methods or constructors as above, those are called by Spring, and the parameters are injected. There can be more than one parameters — all will be injected.

The first example is commonly called setter injection, because the instance method happens to be a setter in this case. The second example is called constructor injection.

In the second example, we can actually omit @Autowired (unless you’re using a Spring version less than 4.3). When Spring will create the instance of MailController, it’ll call the constructor with all the parameters automatically injected. Had there been more than one constructors though, you would have to annotate one with @Autowired.

So, let’s change our MailController as below:

Test it out, if you wish, by running the application and visiting http://localhost:8080/mail.

But what will happen if more than one bean will become eligible for an injection? To check, annotate SmtpMailSender as well with @Component:

Restart the application now, and let’s see what happens.

Oops! Trying to restart, we see an error on the console!

It’s because, when injecting a MailSender to MailController, Spring found more than one candidate beans — the instances of both MockMailSender and SmtpMailSender.

So, how to fix this? There are multiple ways — let’s look at a few.

Now that we have seen constructor, setter and field injections, you may be thinking which one to prefer. The Spring documentation recommends constructor injection in general, and we have the same view.

Spring also provides a @Resource annotation and supports the Java CDI JSR-299 @Inject annotation, which are similar to @Autowired. However, @Autowired should be generally preferred — it’s the most powerful and popular one.

Functionally there are some subtle differences between these three, which won’t matter in most cases though. For example, @Resource first tries to match by name, and then falls back to by type. In contrast, @Autowired and @Inject first try to match by type. David Kessler has written an interesting article on it, if you’re curious.

Spring creates beans for classes annotated with @Component or one of its specializations, e.g.:

In fact, we have already seen @Component and @RestController in action.

The application context is created when the application starts, by calling SpringApplication.run in the main method in the NpSpring5TutorialApplication class.

Notice that NpSpringTutorialApplication is annotated with @SpringBootApplication. This tells Spring to scan for classes that are annotated with @Component, or any of its specialization such as @RestController, and create beans for those. By default, scanning will be done only inside the package (and all sub-packages) of the class that’s is annotated with @SpringBootApplication. If you want some other packages to be scanned as well, there are a few ways to do so. For example, you can pass a scanBasePackageClasses attribute to @SpringBootApplication, as below:

Spring will then scan for the packages of all the given classes, including their sub-packages.

But how to create beans of classes from a third-party JAR, which we can’t annotate with @Component?

In such case, we could use Java configuration classes. To illustrate, remove @Component and any other annotations from SmtpMailSender and MockMailSender. Let them be plain classes, without being aware that they are going to be used by a spring application:

Now create a class, say MailConfig, residing in any package that will be scanned by Spring —  e.g. in the mail package — as below:

Try running the application now, and it’ll work. How?

The @Configuration annotation tells Spring that it’s a configuration class. When the application context is built, the methods that are annotated with @Bean inside such configuration classes are executed, and their return values are stored as beans. The name of the methods become the name of the beans by default.

Like Java configuration classes, we can also use xml files to configure beans. In fact, it was the only way to configure beans in early days of Spring. But it’s normally avoided nowadays. If you want to learn it though, there’s ample material lying on the Internet — so we’ll not cover it in this book.

So, how to make the property value different in a different environment?

There are many ways to do it. A simple way is to place a different application.properties in the folder where application JAR is deployed. Property values in that external application.properties will override those in the internal application.properties.

To see it working, follow these steps:

Now visit http://localhost:8080/hello and you should see the overridden hello message.

So, this was a very simple example of setting property values externally. Spring Boot is very powerful in this area, providing lots of options suiting all kinds of scenarios. Spring Boot reference material has exhaustive documentation on it, and in our Module IV we’ll discuss an elegant pattern for externalizing configuration in real-world applications.

For sending SMTP mails, Spring comes with a JavaMailSender. So, we can plan to configure a JavaMailSender bean, inject that into SmtpMailSender and then use that to send SMTP mails.

Spring Boot will auto-configure a JavaMailSender if it’s found in the classpath and some properties are set. To add it to classpath, simply include the following in pom.xml, in the dependencies section:

Then, for the JavaMailSender to be configured properly, we’ll need to specify a few properties in application.properties. The exact properties to be specified will depend on the SMTP service that we’re planning to use. Looking at MailProperties.java will give you a hint. For using Gmail, specify the following:

from_gmail_id@gmail.com above is the ID from which the mails will be sent. Replace it with an ID that you own. Similarly, replace an_application_password with one of your application passwords.

Let’s now update our SmtpMailSender to send real mails, using the JavaMailSender. It’ll look as below:

In lines 11-16, we declare a JavaMailSender instance variable and a constructor for injecting that. In lines 21-33, we create a MimeMessage and then a MimeMessageHelper. Using that helper, we then set the subject, to, etc. Finally, we send the mail using the javaMailSender.

The above send method has now a throws declaration, which also needs to be added to the MailSender interface and the MailController:

Looking at the SmtpMailSender code above, you may be thinking that the javaMailSender variable there’ll be injected by Spring, because we’ve provided a constructor that should be implicitly @Autowired.

Nope, that’s wrong, because we haven’t annotated the class with @Component, and so Spring won’t create the bean for the class. Instead, we create the bean for the class manually — in the smtpMailSender method of MailConfig class, if you remember. So, we’ll have to inject the variable manually.

One way to do so would be autowiring a JavaMailSender in MailConfig, and supplying that when calling SmtpMailSender’s constructor in the smtpMailSender method, like this:

Instead of autowiring the javaMailSender using field injection as above (lines 4-5), we can also use setter or constructor injection. But, we also can just supply a JavaMailSender as a parameter to the smtpMailSender method, which’ll look much cleaner:

Parameters of methods annotated with @Bean are injected by Spring, and so the above works.

Test sending SMTP mails now! When visiting http://localhost:8080/mail, you’ll now notice that the page will stall for a second or two. To avoid that, we should send mails asynchronously, which we’ll discuss in Module III.