Injecting and Binding Objects to Spring MVC Controllers

I have written two previous posts on how to inject custom, non Spring specific objects into the request handling methods of a controller in Spring MVC. One was using HandlerMethodArgumentResolver
the other with @ModelAttribute.

An adventurous reader of these posts would have discovered, that even if you remove the implemented HandlerMethodArgumentResolver or the @ModelAttribute annotation the custom objects would still be instantiated and provided to the controller method!

Yes, try it!

The only problem is that the properties of the instantiated object would be null, that is they won't have been initialized (this won't be the case though, if these properties are instantiated in the default constructor).

Using Spring's Type Converter to Inject Objects into Spring MVC Controllers

The pattern of having the identity of a resource articulated in the URL is not uncommon; In fact it is one of the ways of expressing RESTful end points...for example in an application that displays details about people, you can have a URL expressed thus:

http://www.example.com/people/777

where 777 is the number that serves as the identifier used to fetch the resources, in this case that could be the corresponding Person Object with an identifier of 777.

It wont be taking it too far then, if we see the number 777, as a direct mapping to the Person object with an id of 777.

In fact the controller method that maps the the URL above may simply have logic that get's the 777 part of the URL and use it to fetch the corresponding entry in the database backing the application. for example:

Injecting Objects into Spring MVC Controller Using @ModelAttribute Annotation

In How to Inject Objects Into Spring MVC Controller Using HandlerMethodArgumentResolver, I showed how to implement the HandlerMethodArgumentResolver interface in other to have a custom object passed as a method argument of a Spring MVC controller.

This post looks at how to still pass objects into the Spring MVC controller, but using a some what different approach: The @ModelAttribute annotation.

The @ModelAttribute annotation can be used to designates operation that can both retrieve and put stuff into the model. Its functionality depends on where it is placed...two places actually: On controller methods and on controller's method arguments.

When @ModelAttribute is placed on a controller's method, it allows the putting of stuff into the Model and when on a controller method arguments, it allows retrieving stuff from the Model...

I thus, like to think of @ModelAttribute as an annotation driven mechanism for writing and reading from the Model.

This post would look at these two methods of using @ModelAttribute and how it can be used to inject objects into controller's methods.

How to Inject Objects Into Spring MVC Controller Using HandlerMethodArgumentResolver

This post shows how to implement HandlerMethodArgumentResolver in other to resolve and inject objects into Spring MVC controllers, but before we get to the actual implementation procedure, a little trivial overview of Spring MVC would be good.

Spring MVC is designed around the Front Controller Pattern which it uses to implement the Model View Controller pattern.

Since you are reading this post, I can rightly assume you already use Spring MVC and you know how it generally works: You register the DispatcherServlet -Spring MVC's Front Controller, write your controller class and map requests to controller methods using @RequestMapping, then put the necessary configuration in place which would enable Spring to pick the written controller class and have it as a spring managed bean.

A trivial controller class may look like this:

package com.springapp.mvc;

import org.springframework.stereotype.Controller;
import org.springframework.ui.Model;
import org.springframework.web.bind.annotation.RequestMapping;


@Controller
public class HelloController {


    @RequestMapping("/index")
    public String doGreeting(Model model) {
        model.addAttribute("greet", "Hello World");
        return "helloView";
    }
}

So when a request hits /index, doGreeting(...) method is invoked with an object of Model (the M in MVC) passed into it, which is populated with the greet property which can then be accessed in whatever view technology in used. The view is located using the "helloView" string returned by the controller.

Configuring Spring MVC

tl;dr The process of configuring Spring MVC involves configuring the DispatcherServler as a front controller in the web.xml and configuring the Spring context file where Spring MVC specific beans like Controllers, Handler mappings, View resolvers, Locale resolver and Theme resolver can be wired.

This post is about how to configure Spring MVC. It is part of the Configuring Spring Series.

Spring MVC allows you to put the Spring framework at the fore front of your web layer. As you probably know, it is possible to use Spring in a web application without Spring MVC. As mentioned in Configuring Beans In Spring Framework, you can use WebApplicationContextUtils to bring in the Spring context into your web application. In that scenario, Spring is not responsible for the whole Web layer, it just plays its part, mostly as a DI container. But with Spring MVC, Spring framework is put at a central and integral part of your web layer.

Dependencies

I would be using Maven for dependency management. To get Spring MVC, certain required artifacts needs to be added to your project. To get these dependencies with Maven, your pom.xml file may look thus:

Fixing org.springframework.http.converter.HttpMessageNotWritableException Error

A couple of days back, I ran into an interesting error while retrieving persisted entities as JSON  in SpringMVC:

[Request processing failed; nested exception is org.springframework.http.converter.HttpMessageNotWritableException: Could not write JSON: Infinite recursion (StackOverflowError)...

I had to do some poking around and reading up on documentation to figure out how to fix it.

As it turned out, the fix wasn't that complex and the culprit was Jackson: the Java-JSON processor being used to transform the retrieved Java entity to a JSON representation.

The error occurs when you try to retrieve an entity that has a bi-directional @OneToMany relationship with another entity.