In any Spring app, you can choose to declare a bean as one of the following:

• Singleton—The default bean scope in Spring, for which the framework uniquely identifies each instance with a name in the context
• Prototype—The bean scope in Spring, for which the framework only manages the type and creates a new instance of that class every time someone requests it (directly from the context or through wiring or auto-wiring).

In web apps you can use other bean scopes that are relevant only to web applications. We call them web scopes:

• Request scope—Spring creates an instance of the bean class for every HTTP request. The instance exists only for that specific HTTP request.
• Session scope—Spring creates an instance and keeps the instance in the server’s memory for the full HTTP session. Spring links the instance in the context with the client’s session.
• Application scope —The instance is unique in the app’s context, and it’s available while the app is running.

To teach you how these web scopes work in a Spring application, we’ll work on an example in which we implement a login functionality. Most of the web apps today offer their users the possibility to log in and access an account, so the example is also relevant from a real-world perspective. We’ll implement the login functionality in three steps. For each step we implement, we’ll need to use a different bean scope:

Using the request scope in a Spring web app

A request-scoped bean is an object managed by Spring, for which the framework creates a new instance for every HTTP request. The app can use the instance only for the request that created it. Any new HTTP request (from the same or other clients) creates and uses a different instance of the same class:

Let’s demonstrate the use of a request-scoped bean in an example. We’ll implement a web application’s login functionality, and we’ll use a request-scoped bean to manage the user’s credentials for the login logic.

KEY ASPECTS OF REQUEST-SCOPED BEANS

Before diving into implementing a Spring app that uses request-scoped beans, I’d like to shortly enumerate here the key aspects of using this bean scope. These aspects will help you analyze whether a request-scoped bean is the right approach in a real-world scenario. Keep in mind the very relevant aspects of request-scoped beans, explained in the following table.

To make things straightforward, we will consider a set of credentials that we bake into our application. In a real-world app, the app stores the users in a database. It also encrypts the passwords to protect them. For now, we focus only on the purpose of this chapter: discussing the Spring web bean scopes. Later, in chapters 10 and 11, you’ll learn more about storing data in a database.

Let’s create a Spring Boot project and add the needed dependencies:

<dependency>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-starter-thymeleaf</artifactId>
</dependency>
<dependency>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-starter-web</artifactId>
</dependency>

We’ll create a page that contains a login form asking for a user’s name and password. The app compares the username and the password with a set of credentials it knows (in my case, user “natalie” with password “password”). If we provide correct credentials (they match with the credentials the app knows), then the page displays a message “You are now logged in” under the login form. If the credentials we provide are not correct, then the app displays a message: “Login failed.”