Spring MVC¶

Spring MVC framework is a robust Model view controller framework which helps us to develop a loosely coupled web application. It separates different aspects of web applications with the help of MVC architecture.

Model: Model carries application data. It generally includes POJO in the form of business objects

View: View is used to render User interface (UI). It will render application data on UI. For example JSP

Controller: Controller takes care of processing user request and calling back end services.

It has a central servlet called as DispatcherServlet which is well known as front controller that intercepts all the requests, identify the appropriate handler i.e. controllers and render views to the client.

It is defined at org.springframework.web.servlet.DispatcherServlet in org.springframework.web package.

Spring MVC flow¶

In Spring Web MVC, DispatcherServlet class works as the front controller. It is responsible to manage the flow of the spring mvc application.

The @Controller annotation is used to mark the class as the controller in Spring 3.

The @RequestMapping annotation is used to map the request url. It is applied on the method.

Spring MVC Execution Flow¶

Step 1: First request will be received by DispatcherServlet.
Step 2: DispatcherServlet will take the help of HandlerMapping and get to know the Controller class name associated with the given request.
Step 3: So request transfer to the Controller, and then controller will process the request by executing appropriate methods and returns ModelAndView object (contains Model data and View name) back to the DispatcherServlet.
Step 4: Now DispatcherServlet send the model object to the ViewResolver to get the actual view page.
Step 5: Finally DispatcherServlet will pass the Model object to the View page to display the result.

Spring Web Annotations¶

@RequestMapping ¶

it can be configured using:

path, or its aliases, name, and value: which URL the method is mapped to
method: compatible HTTP methods
params: filters requests based on presence, absence, or value of HTTP parameters
headers: filters requests based on presence, absence, or value of HTTP headers
consumes: which media types the method can consume in the HTTP request body
produces: which media types the method can produce in the HTTP response body

Example:

@Controller
class VehicleController {

    @RequestMapping(value = "/vehicles/home", method = RequestMethod.GET)
    String home() {
        return "home";
    }
}

this configuration has the same effect :

@Controller
@RequestMapping(value = "/vehicles", method = RequestMethod.GET)
class VehicleController {

    @RequestMapping("/home")
    String home() {
        return "home";
    }
}

Moreover, @GetMapping, @PostMapping, @PutMapping, @DeleteMapping, and @PatchMapping are different variants of @RequestMapping with the HTTP method already set to GET, POST, PUT, DELETE, and PATCH respectively.

These are available since Spring 4.3 release.

@RequestBody ¶

maps the body of the HTTP request to an object.The deserialization is automatic and depends on the content type of the request.

@PostMapping("/save")
void saveVehicle(@RequestBody Vehicle vehicle) {
    // ...
}

@PathVariable ¶

This annotation indicates that a method argument is bound to a URI template variable. We can specify the URI template with the @RequestMapping annotation and bind a method argument to one of the template parts with @PathVariable.

We can achieve this with the name or its alias, the value argument:

@RequestMapping("/{id}")
Vehicle getVehicle(@PathVariable("id") long id) {
    // ...
}

If the name of the part in the template matches the name of the method argument, we don't have to specify it in the annotation:

@RequestMapping("/{id}")
Vehicle getVehicle(@PathVariable long id) {
    // ...
}

Moreover, we can mark a path variable optional by setting the argument required to false:

@RequestMapping("/{id}")
Vehicle getVehicle(@PathVariable(required = false) long id) {
    // ...
}

@RequestParam ¶

We use @RequestParam for accessing HTTP request parameters:

@RequestMapping
Vehicle getVehicleByParam(@RequestParam("id") long id) {
    // ...
}

It has the same configuration options as the @PathVariable annotation.

In addition to those settings, with @RequestParam we can specify an injected value when Spring finds no or empty value in the request. To achieve this, we have to set the defaultValue argument.

Providing a default value implicitly sets required to false:

@RequestMapping("/buy")
Car buyCar(@RequestParam(defaultValue = "5") int seatCount) {
    // ...
}

Response Handling Annotations

@ResponseBody ¶

If we mark a request handler method with @ResponseBody, Spring treats the result of the method as the response itself:

@ResponseBody
@RequestMapping("/hello")
String hello() {
    return "Hello World!";
}

@ExceptionHandler ¶

With this annotation, we can declare a custom error handler method. Spring calls this method when a request handler method throws any of the specified exceptions.

The caught exception can be passed to the method as an argument:

@ExceptionHandler(IllegalArgumentException.class)
void onIllegalArgumentException(IllegalArgumentException exception) {
    // ...
}

@ResponseStatus ¶

We can specify the desired HTTP status of the response if we annotate a request handler method with this annotation. We can declare the status code with the code argument, or its alias, the value argument.

Also, we can provide a reason using the reason argument.

We also can use it along with @ExceptionHandler:

@ExceptionHandler(IllegalArgumentException.class)
@ResponseStatus(HttpStatus.BAD_REQUEST)
void onIllegalArgumentException(IllegalArgumentException exception) {
    // ...
}

Other Web Annotations

@Controller ¶

We can define a Spring MVC controller with @Controller.@Controller is a class level annotation which tells the Spring Framework that this class serves as a controller in Spring MVC:

@Controller
public class VehicleController {
    // ...
}

@RestController ¶

The @RestController combines @Controller and @ResponseBody.

@Controller
@ResponseBody
class VehicleRestController {
    // ...
}

is same as :

@RestController
class VehicleRestController {
    // ...
}

@ModelAttribute ¶

With this annotation we can access elements that are already in the model of an MVC @Controller, by providing the model key:

@PostMapping("/assemble")
void assembleVehicle(@ModelAttribute("vehicle") Vehicle vehicleInModel) {
    // ...
}

Like with @PathVariable and @RequestParam, we don't have to specify the model key if the argument has the same name:

@PostMapping("/assemble")
void assembleVehicle(@ModelAttribute Vehicle vehicle) {
    // ...
}

Besides, @ModelAttribute has another use: if we annotate a method with it, Spring will automatically add the method's return value to the model:

@ModelAttribute("vehicle")
Vehicle getVehicle() {
    // ...
}

Like before, we don't have to specify the model key, Spring uses the method's name by default:

@ModelAttribute
Vehicle vehicle() {
    // ...
}

Before Spring calls a request handler method, it invokes all @ModelAttribute annotated methods in the class.

@CrossOrigin ¶

@CrossOrigin enables cross-domain communication for the annotated request handler methods: If we mark a class with it, it applies to all request handler methods in it.

@CrossOrigin
@RequestMapping("/hello")
String hello() {
    return "Hello World!";
}

@Autowired ¶

Since version 2.5, Spring provides the @Autowired annotation to discover the beans automatically and inject collaborating beans (other associated dependent beans) into our bean.

By declaring all the beans in Spring Configuration file, Spring container can autowire relationships between collaborating beans.

After enabling annotation based injection, now we can use @Autowired annotation. @Autowired can be used on following injection points.

Constructors
Methods
Fields and
Parameters

and dependencies can be injected using by type OR by name OR by @Qualifier.

In spring there are two types of autowiring. Those are - Autowiring by type : @Autowired by type uses the class type to autowire the spring boot bean class. The bean is autowired based on the type of the variable. - Autowiring by name : For Autowiring by name, the name of the variable is used for the dependency injection. The name of the authoring variable should be the same as the name of the class or the bean name configured in the @Component annotation.

For example,

public interface Shape {
    public void draw();
}

@Component
public class Rectangle implements Shape {
    @Override
    public void draw() {
        System.out.println(">>>>>>>>>>>>>INVOKING THE RECTANGLE INSTANCE<<<<<<<<<<<<<<<<");
    }
}

@Component
public class Circle implements Shape{
    @Override
    public void draw() {
        System.out.println(">>>>>>>>>>>>>INVOKING THE CIRCLE INSTANCE<<<<<<<<<<<<<<<<");
    }
}

the shape interface is implemented by two classes Circle and Rectangle. So we can say both are instances of Shape or both shape. It made Rectangle and Circle as spring beans using the annotation @Component. Now let's see how to autowire these beans in another class.

@Component
public class ShapeService {
    @Autowired
    private Shape rectangle;//by name

    @Autowired
    private Rectangle myRectangle;//by type

}

Here in ShapeService class, it is autowring the shape Rectangle in two ways. 1. Here in the first @Autowiring, the variable rectangle is autowired based on the name of the variable. Here when the spring checks the type of the variable, he can see it is Shape. But there are two shape implementations are there Rectangle and Circle. So spring doesn't get a proper solution for what component need to autowire. Then the spring check the name of the variable(rectangle) and find out any Shape component with the same name is available. Yes…The Rectangle component is available. So the spring will inject the property with rectangle component. 2. In the second @Autowiring, the type of property is Rectangle. So the spring directly injects the Rectangle component to the property myRectangle.

@Inject vs @Autowired ¶

Key	@Inject	@Autowired
Basic	It is part of Java CDI(Contexts and Dependency Injection)	It is part of Spring framework
Required	It has no required attribute	It has required attribute
Default Scope	Default scope of the autowired beans is Singleton	Default scope of the inject beans is prototype
Ambiguity	In case of ambiguity in beans for injection then @Named qualifier should be added in your code.	In case of ambiguity in beans for injection then @Qualifer qualifier should be added in your code.
Advantage	It is a part of Java CDI so it is not dependent on any DI framework. It makes your system loosely coupled.	It makes your application tightly coupled with Spring framework. In the future , if you want to move to another DI framework then you need reconfigure your application.

@Validated ¶

@Validated annotation activates the Spring Validation AOP interceptor and it will examine method parameters to see if they have any validation annotations on them, if they do then Spring will call hibernate validator with each specific annotation for example @Size(min = 8) String password means call hibernate size validator and pass the value of the parameter password in this case hibernate validator does not need to scan java.lang.String to see if it has validation annotations on it. @Validated works on any spring @Component you can use it on @Service classes for example.

@Valid vs @Validated ¶

In Spring, we use JSR-303's @Valid annotation for method level validation. We also use it to mark a member attribute for validation. However, this annotation doesn't support group validation.

Groups help to limit the constraints applied during validation. One particular use case is UI wizards. In the first step, we may have a certain sub-group of fields. In the subsequent step, there may be another group belonging to the same bean. So we need to apply constraints on these limited fields in each step, but @Valid doesn't support this.

In this case, for group-level, we have to use Spring's @Validated, which is a variant of JSR-303's @Valid. This is used at the method-level. For marking member attributes, we continue to use the @Valid annotation.

Component Scanning¶

To do dependency injection, Spring creates a so-called application context.

During startup, Spring instantiates objects and adds them to the application context. Objects in the application context are called “Spring beans” or “components”.

Spring resolves dependencies between Spring beans and injects Spring beans into other Spring beans’ fields or constructors.

The process of searching the classpath for classes that should contribute to the application context is called component scanning.

When developing Spring Boot applications, you need to tell the Spring Framework where to look for Spring components. Using component scan is one method of asking Spring to detect Spring managed components. Spring needs the information to locate and register all the Spring components with the application context when the application starts.

Spring can auto scan, detect, and instantiate components from pre-defined project packages. It can auto scan all classes annotated with the stereotype annotations @Component @Controller, @Service and @Repository

@ComponentScan ¶

@ComponentScan tells Spring in which packages you have annotated classes which should be managed by Spring. So, for example, if you have a class annotated with @Controller which is in a package which is not scanned by Spring, you will not be able to use it as Spring controller.

Classes annotated with @Configuration is a new way of configuring Spring using annotations instead of XML files (it's called Java configuration). Spring needs to know which packages contain spring beans, otherwise you would have to register each bean individually. That's what @ComponentScan is used for.

@ComponentScan Without Arguments¶

we use the @ComponentScan annotation along with the @Configuration annotation to specify the packages that we want to be scanned. @ComponentScan without arguments tells Spring to scan the current package and all of its sub-packages.

@Configuration
@ComponentScan
public class DemoAppConfig {
    //...
}

@ComponentScan With Arguments¶

@Configuration
@ComponentScan(basePackages = {"basic.ioc.autowire", "basic.ioc.setter"})
public class AutowireBeanConfig {
    //other configs
}

@ComponentScan with Exclusions¶

Use a filter,with the pattern for the classes to exclude:

    @Configuration
@ComponentScan(basePackages = "com.demo",
        includeFilters = @Filter(type = FilterType.REGEX, pattern = ".*Dao"),
        excludeFilters = @Filter(Repository.class))
public class AppConfig {
        ...
}

@ComponentScan in a Spring-Boot application¶

Spring-Boot application, we don’t need to specify the @Configuration annotation unless we want more control over the classpath scanning. This is because of the @SpringBootApplication , which is already a combination of below listed three annotations.

Difference between @Component, @Repository & @Service annotations?¶

From Spring Documentation:

Spring provides stereotype annotations: @Component, @Service, and @Controller. @Component is a generic stereotype for any Spring-managed component. @Repository, @Service, and @Controller are specializations of @Component for more specific use cases (in the persistence, service, and presentation layers, respectively). Therefore, you can annotate your component classes with @Component, but, by annotating them with @Repository, @Service, or @Controller instead, your classes are more properly suited for processing by tools or associating with aspects.

@Repository ¶

stereotype for persistence layer

@Repository’s job is to catch persistence-specific exceptions and re-throw them as one of Spring’s unified unchecked exceptions.

For this, Spring provides PersistenceExceptionTranslationPostProcessor, which we are required to add in our application context (already included if we're using Spring Boot):

<bean class="org.springframework.dao.annotation.PersistenceExceptionTranslationPostProcessor"/>

This bean post processor adds an advisor to any bean that’s annotated with @Repository.

@Service ¶

stereotype for service layer

We mark beans with @Service to indicate that they're holding the business logic. Besides being used in the service layer, there isn't any other special use for this annotation.

@Controller ¶

stereotype for presentation layer (spring-mvc)

Instead of using @Component on a controller class in Spring MVC, we use @Controller, which is more readable and appropriate.

By using that annotation we do two things, first, we declare that this class is a Spring bean and should be created and maintained by Spring ApplicationContext, but also we indicate that its a controller in MVC setup. This latter property is used by web-specific tools and functionalities.

For example, DispatcherServlet will look for @RequestMapping on classes that are annotated using @Controller but not with @Component.

This means @Component and @Controller are the same with respect to bean creation and dependency injection but later is a specialized form of former. Even if you replace @Controller annotation with @Compoenent, Spring can automatically detect and register the controller class but it may not work as you expect with respect to request mapping.

Scheduler in cluster environment or run on multiple instances¶

Spring provides an easy to implement API for scheduling jobs. It works great until we deploy multiple instances of our application. Spring, by default, cannot handle scheduler synchronization over multiple instances – it executes the jobs simultaneously on every node instead.

In this short tutorial, we'll look at ShedLock – a Java library that makes sure our scheduled tasks run only once at the same time and is an alternative to Quartz.

Spring Scheduled Task running in clustered environment with ShedLock¶

To use ShedLock with Spring, we need to add the shedlock-spring dependency:

<dependency>
    <groupId>net.javacrumbs.shedlock</groupId>
    <artifactId>shedlock-spring</artifactId>
    <version>2.2.0</version>
</dependency>

Configuration¶

ShedLock works only in environments with a shared database by declaring a proper LockProvider. It creates a table or document in the database where it stores the information about the current locks.

For this example,we can usein-memory H2 database.We need to provide the H2 database and the ShedLock's JDBC dependency:

<dependency>
    <groupId>net.javacrumbs.shedlock</groupId>
    <artifactId>shedlock-provider-jdbc-template</artifactId>
    <version>2.1.0</version>
</dependency>
<dependency>
<groupId>com.h2database</groupId>
<artifactId>h2</artifactId>
<version>1.4.200</version>
</dependency>

Next, we need to create a database table for ShedLock to keep information about scheduler locks:

CREATE TABLE shedlock (
   name VARCHAR(64),
   lock_until TIMESTAMP(3) NULL,
   locked_at TIMESTAMP(3) NULL,
   locked_by VARCHAR(255),
   PRIMARY KEY (name)
)

application.yaml file configuration:

spring:
    datasource:
        driverClassName: org.h2.Driver
        url: jdbc:h2:mem:shedlock_DB;INIT=CREATE SCHEMA IF NOT EXISTS shedlock;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE
        username: sa
        password:

SchedulerConfiguration.java:

@Configuration
public class SchedulerConfiguration {
    @Bean
    public LockProvider lockProvider(DataSource dataSource) {
        return new JdbcTemplateLockProvider(dataSource);
    }
}

Application.java:

@SpringBootApplication
@EnableScheduling
@EnableSchedulerLock(defaultLockAtMostFor = "PT30S")
public class Application {

    public static void main(String[] args) {
        SpringApplication.run(SpringApplication.class, args);
    }
}

Creating Tasks¶

To create a scheduled task handled by ShedLock, we simply put the @Scheduled and @SchedulerLock annotations on a method:

TaskScheduler.java:

@Component
class TaskScheduler {

    @Scheduled(cron = "0 0/15 * * * ?")
    @SchedulerLock(name = "TaskScheduler_scheduledTask",
            lockAtLeastForString = "PT5M", lockAtMostForString = "PT14M")
    public void scheduledTask() {
        // ...
    }
}

@Scheduled supports the cron format, with this expression meaning “every 15 minutes”.

Next, taking a look at @SchedulerLock, the name parameter has to be unique, and ClassName_methodName is typically enough to achieve that. We don't want more than one run of this method happening at the same time, and ShedLock uses the unique name to achieve that.

First, we've added lockAtLeastForString so that we can put some distance between method invocations. Using “PT5M” means that this method will hold the lock for 5 minutes, at a minimum. In other words, that means that this method can be run by ShedLock no more often than every five minutes.

Next, we added lockAtMostForString to specify how long the lock should be kept in case the executing node dies. Using PT14M means that it will be locked for no longer than 14 minutes.

In normal situations, ShedLock releases the lock directly after the task finishes. Now, we didn't have to do that because there is a default provided in @EnableSchedulerLock, but we've chosen to override that here.

Execute a Quartz Job only once in a multi-instance environment¶

You have to configure Quartz to run in a clustered environment. Clustering currently only works with the JDBC jobstore, and works by having each node of the cluster to share the same database.

Set the org.quartz.jobStore.isClustered property to true if you have multiple instances of Quartz that use the same set of database tables. This property is used to turn on the clustering features.
Set the org.quartz.jobStore.clusterCheckinInterval property (milliseconds) which is the frequency at which this instance checks in with the other instances of the cluster.
Set the org.quartz.scheduler.instanceId to AUTO so that each node in the cluster will have a unique instanceId.

Each instance in the cluster should use the same copy of the quartz.properties file. If you use clustering on separate machines ensure that their clocks are synchronized.

Example Properties For A Clustered Scheduler

#============================================================================
# Configure Main Scheduler Properties  
#============================================================================

org.quartz.scheduler.instanceName = MyClusteredScheduler
org.quartz.scheduler.instanceId = AUTO

#============================================================================
# Configure ThreadPool  
#============================================================================

org.quartz.threadPool.class = org.quartz.simpl.SimpleThreadPool
org.quartz.threadPool.threadCount = 25
org.quartz.threadPool.threadPriority = 5

#============================================================================
# Configure JobStore  
#============================================================================

org.quartz.jobStore.misfireThreshold = 60000

org.quartz.jobStore.class = org.quartz.impl.jdbcjobstore.JobStoreTX
org.quartz.jobStore.driverDelegateClass = org.quartz.impl.jdbcjobstore.oracle.OracleDelegate
org.quartz.jobStore.useProperties = false
org.quartz.jobStore.dataSource = myDS
org.quartz.jobStore.tablePrefix = QRTZ_

org.quartz.jobStore.isClustered = true
org.quartz.jobStore.clusterCheckinInterval = 20000

#============================================================================
# Configure Datasources  
#============================================================================

org.quartz.dataSource.myDS.driver = oracle.jdbc.driver.OracleDriver
org.quartz.dataSource.myDS.URL = jdbc:oracle:thin:@polarbear:1521:dev
org.quartz.dataSource.myDS.user = quartz
org.quartz.dataSource.myDS.password = quartz
org.quartz.dataSource.myDS.maxConnections = 5
org.quartz.dataSource.myDS.validationQuery=select 0 from dual

Spring MVC¶

Spring MVC¶

Spring MVC flow¶

Spring MVC Execution Flow¶

Spring Web Annotations¶

@Inject vs @Autowired¶

@Valid vs @Validated¶

Component Scanning¶

@ComponentScan Without Arguments¶

@ComponentScan With Arguments¶

@ComponentScan with Exclusions¶

@ComponentScan in a Spring-Boot application¶

Difference between @Component, @Repository & @Service annotations?¶

Scheduler in cluster environment or run on multiple instances¶

Spring Scheduled Task running in clustered environment with ShedLock¶

Configuration¶

Creating Tasks¶

Execute a Quartz Job only once in a multi-instance environment¶

Reference Links¶

@Inject vs @Autowired ¶

@Valid vs @Validated ¶