slides

z, ?	toggle help (this)
space, →	next slide
shift-space, ←	previous slide
d	toggle debug mode
## <ret>	go to slide #
c, t	table of contents (vi)
f	toggle footer
r	reload slides
n	toggle notes
p	run preshow

loading presentation...

Spring MVC 3.1 In-Depth

Rossen Stoyanchev

SpringSource, VMware

MVC Java Config Design

Design goals

A simple starting point
Transparency
Flexibility
A path from simple to advanced

Why does it matter?

It's a relatively simple mechanism worth understanding

You may use for your own purposes, e.g.

to design your your own `@EnableXyz`

A simple starting point


    @EnableWebMvc
    @Configuration
    public class WebConfig {

    }

No base class

No Spring MVC beans in sight

What it provides

@MVC request processing
ConversionService
Global JSR-303 validator
HttpMessageConverter registrations
A few others

What can be customized

Implement WebMvcConfigurer
Or extend WebMvcConfigurerAdapter

Still no Spring beans

Implement an interface and magic happens

Demo

SPR-0000-war-java

No Spring beans

Implement an interface and magic happens

How does it work?


    @EnableWebMvc  // <-- What's behind?
    @Configuration
    public class WebConfig {

    }

`@EnableWebMvc`


    @Retention(RetentionPolicy.RUNTIME)
    @Import(DelegatingWebMvcConfiguration.class)
    @Target(ElementType.TYPE)
    public @interface EnableWebMvc {

    }

`@EnableWebMvc`



    @Import(DelegatingWebMvcConfiguration.class)

    public @interface EnableWebMvc {

    }

The configuration is imported

`WebMvcConfigurationSupport`

Contains the imported configuration
Uses @Bean methods
Just like your configuration
Easy to read

Demo

How does importing the configuration allow for customizations?

Recall that we

implement an interface and magic happens

`DelegatingWebMvcConfigurationSupport`

A sub-class of WebMvcConfigurationSupport
"Detects" WebMvcConfigurer implementations
Via @Autowired
Delegates to detected instances to customize the config

However at any point you can switch

to extending directly from

`WebMvcConfigurationSupport`

Extending directly from `WebMvcConfigurationSupport`

Remove @EnableWebMvc
i.e. don't import
Extend WebMvcConfigurationSupport
Override @Bean and other available methods

The New
@MVC Support Classes

Old

`DefaultAnnotationHandlerMapping`, `AnnotationMethodHandlerAdapter`, `AnnotationMethodExceptionResolver`

New

`RequestMappingHandlerMapping`, `RequestMappingHandlerAdapter`, `ExceptionHandlerExceptionResolver`

Why the re-write?

General Background

JIRA tickets for more flexibility
A few functional limitations
A few tricky request mapping semantics

The ticket that

happened to tip the balance

SPR-7345

Relatively insignificant
Not many comments
Nevertheless worth a closer look
A representative example

The issue

404 expected
405 (METHOD_NOT_SUPPORTED) returned
?

The code


// GET /foo Accept=text/html

@Controller
public FooController {



  @RequestMapping(value = "/foo",
                  method=RequestMethod.GET, 
                  headers="Accept=text/plain")
  public @ResponseBody Foo getValue() {

  }


}

The code


// GET /foo Accept=text/html    <- Accept header

@Controller
public FooController {



  @RequestMapping(value = "/foo",
                  method=RequestMethod.GET, 
                  headers="Accept=text/plain")  // No match
  public @ResponseBody Foo getValue() {

  }


}

Old @MVC

Request Mapping Process

Two stages
HandlerMapping selects controller
Perhaps not from annotations!
HandlerAdapter narrows down the method

Designed to work with

different `HandlerMapping` types

E.g.

`SimpleUrlHandlerMapping`
and others

Sounds reasonable but..

Controller is chosen mainly based on URL + type-level @RequestMapping attributes
Method-level @RequestMapping attributes deferred to HandlerAdapter
Splits decision making process

Back to the code


// GET /foo Accept=text/html

@Controller
public FooController {




  @RequestMapping(value = "/foo",
                  method=RequestMethod.GET, 
                  headers="Accept=text/plain")
  public @ResponseBody Foo getValue() {

  }


}

Back to the code


// GET /foo Accept=text/html

@Controller  // (1) Controller selected based on "/foo"
public FooController {




  @RequestMapping(value = "/foo",
                  method=RequestMethod.GET, 
                  headers="Accept=text/plain")
  public @ResponseBody Foo getValue() {

  }


}

Back to the code


// GET /foo Accept=text/html

@Controller  // (1) Controller selected based on "/foo"
public FooController {

  // (2) Only to find later that method doesn't match


  @RequestMapping(value = "/foo",
                  method=RequestMethod.GET, 
                  headers="Accept=text/plain")
  public @ResponseBody Foo getValue() {

  }


}

Back to the code


// GET /foo Accept=text/html

@Controller  // (1) Controller selected based on "/foo"
public FooController {

  // (2) Only to find later that method doesn't match
  // (3) Harder to reason at this stage about the error

  @RequestMapping(value = "/foo",
                  method=RequestMethod.GET, 
                  headers="Accept=text/plain")
  public @ResponseBody Foo getValue() {

  }


}

Other limitations of prior approach

One URL per controller
Controller method not known to HandlerInterceptor
Ditto for HandlerExceptionResolver
Harder to reason about the process

New @MVC

HandlerMethod abstraction
Think of methods as endpoints
Each endpoint must be uniquely mapped!

A single point of decision

HandlerMapping selects a HandlerMethod
Not a controller
HandlerAdapter invokes selected method
Doesn't know how it's chosen

The code re-visited with 3.1


// GET /foo Accept=text/html

@Controller
public FooController {




  @RequestMapping(value = "/foo",
                  method=RequestMethod.GET, 
                  headers="Accept=text/plain")
  public @ResponseBody Foo getValue() {

  }

}

The code re-visited with 3.1


// GET /foo Accept=text/html

@Controller
public FooController {

  // A single point of decision


  @RequestMapping(value = "/foo",
                  method=RequestMethod.GET, 
                  headers="Accept=text/plain")
  public @ResponseBody Foo getValue() {

  }

}

The code re-visited with 3.1


// GET /foo Accept=text/html

@Controller
public FooController {

  // A single point of decision
  // Result is 406 (NOT_ACCEPTABLE)

  @RequestMapping(value = "/foo",
                  method=RequestMethod.GET, 
                  headers="Accept=text/plain")
  public @ResponseBody Foo getValue() {

  }

}

The code re-visited with 3.1


// GET /foo Accept=text/html

@Controller
public FooController {

  // A single point of decision
  // Result is 406 (NOT_ACCEPTABLE)

  @RequestMapping(value = "/foo",
                  method=RequestMethod.GET, 
                  produces="text/plain") // <-- produces
  public @ResponseBody Foo getValue() {

  }

}

Other limitations lifted

Same URL processing can be
split across controllers
Controller method known to HandlerInterceptor, HandlerExceptionResolver

Demo

spring-mvc-31-demo

Incidentally after the 3.1 release we had this ticket

SPR-9063

The following code worked in 3.0
Treated as "ambiguous mapping" in 3.1

The code




@Controller
@RequestMapping(value = "/foo",
    method = {RequestMethod.GET, RequestMethod.POST })
public class FooController {

    @RequestMapping(method = RequestMethod.GET)
    public String index() {
        return "form";
    }

    @RequestMapping(method = RequestMethod.POST)
    public String submit() {
        return "success";
    }

}

The code


// Can you guess why {GET, POST} are on the type level?

@Controller
@RequestMapping(value = "/foo",
    method = {RequestMethod.GET, RequestMethod.POST })
public class FooController {

    @RequestMapping(method = RequestMethod.GET)
    public String index() {
        return "form";
    }

    @RequestMapping(method = RequestMethod.POST)
    public String submit() {
        return "success";
    }

}

The code


// Note the extra type-level HTTP methods!

@Controller
@RequestMapping(value = "/foo",
    method = {RequestMethod.GET, RequestMethod.POST })
public class FooController {

    @RequestMapping(method = RequestMethod.GET)
    public String index() {
        return "form";
    }

    @RequestMapping(method = RequestMethod.POST)
    public String submit() {
        return "success";
    }

}

The code with the new @MVC

Just remove the type-level HTTP method mapping


@Controller
@RequestMapping(value = "/foo")
public class FooController {

    @RequestMapping(method = RequestMethod.GET)
    public String index() {
        return "form";
    }

    @RequestMapping(method = RequestMethod.POST)
    public String submit() {
        return "success";
    }

}

Is it not a regression?

The upgrade path

Automatic upgrade with the
MVC namespace or MVC Java config
You must update configuration otherwise
We recommended you do so
No more new features on old @MVC

`HandlerMethod`:

An abstraction for various controller methods

@RequestMapping
@ModelAttribute
@InitBinder
@ExceptionHandler

How different method arguments are supported



public interface HandlerMethodArgumentResolver {

  boolean supportsParameter(MethodParameter parameter);

  Object resolveArgument(
      MethodParameter parameter, 
      ModelAndViewContainer mavContainer,
      NativeWebRequest webRequest, 
      WebDataBinderFactory binderFactory) throws Exception;

}

Every built-in method argument has its own `HandlerMethodArgumentResolver`

How different return value types are supported



public interface HandlerMethodReturnValueHandler {

  boolean supportsReturnType(MethodParameter returnType);

  void handleReturnValue(
    Object returnValue,
    MethodParameter returnType,
    ModelAndViewContainer mavContainer,
    NativeWebRequest webRequest) throws Exception;

}

Every supported return value has its own `HandlerMethodReturnValueHandler`

The benefits

More flexible
More customizable
Better flexible method signature support

Demo

Redirect Attributes

This stack overflow post describes the motivation

`RedirectAttributes` Example


    @RequestMapping(method=POST)
    public String save(Entity entity, Errors errors,
                       RedirectAttributes redirectAttrs){

        // ...

        redirectAttrs.addAttribute("id", entity.getId);
        redirectAttrs.addAttribute("date", new Date());

        // ...

        redirectAttrs.addFlashAttribute("message", "Yay!");

        return "redirect:/someUrl";
    }

Why not just use the `Model`?

The Model has the right content for rendering
Not so much for redirecting
It's usually a different set of attributes
Prefer RedirectAttributes when redirecting for better control

This is possible


@RequestMapping(method=POST)
public String save(Entity entity, Errors errors,
                   Model model,
                   RedirectAttributes redirectAttrs){


    // Use Model if not redirecting (e.g. Ajax request)


    // Use RedirectAttrs otherwise

}

Demo

FormController.java

spring-mvc-showcase

How to enable use of `RedirectAttributes` for all redirects

For example when method signature does not contain RedirectAttributes

Example


@RequestMapping(method=POST)
public String save(Entity e, Errors errors, Model model){

    // ...

    return "redirect:/someUrl";
}

Use `RedirectAttributes` for all redirects

RequestMappingHandlerAdapter property
setIgnoreDefaultModelOnRedirect

Flash attributes

Redirect URL is the intended recipient
But what if another request comes in meanwhile?
Not so unlikely with Ajax requests
Potentially not consumed by intended recipient

`FlashMap`

Contains properties with target URL + params
Auto-populated by RedirectView
After the redirect FlashMapManager tries to match request to FlashMap instances

Looking Forward

Spring 3.2

Async request processing
spring-test-mvc
@Resource stereotype SPR-8406
Content negotiation refinements SPR-8410
Global @ExceptionHandler methods
Much more

Hwo to get involved

The Spring Framework now on Github
spring-framework-issues repository
New Gradle-based build (Wiki)
New SpringSource repository (Wiki)
Spring JIRA

Spring MVC 3.1 In-Depth

Rossen Stoyanchev

SpringSource, VMware

MVC Java Config Design

Design goals

Why does it matter?

It's a relatively simple mechanism worth understanding

You may use for your own purposes, e.g.

to design your your own @EnableXyz

A simple starting point

No base class

No Spring MVC beans in sight

What it provides

What can be customized

Still no Spring beans

Implement an interface and magic happens

Demo

SPR-0000-war-java

No Spring beans

Implement an interface and magic happens

How does it work?

@EnableWebMvc

@EnableWebMvc

The configuration is imported

WebMvcConfigurationSupport

Demo

How does importing the configuration allow for customizations?

Recall that we

implement an interface and magic happens

DelegatingWebMvcConfigurationSupport

However at any point you can switch

to extending directly from

WebMvcConfigurationSupport

Extending directly from WebMvcConfigurationSupport

The New @MVC Support Classes

Old

DefaultAnnotationHandlerMapping, AnnotationMethodHandlerAdapter, AnnotationMethodExceptionResolver

New

RequestMappingHandlerMapping, RequestMappingHandlerAdapter, ExceptionHandlerExceptionResolver

Why the re-write?

General Background

The ticket that

happened to tip the balance

SPR-7345

The issue

The code

The code

Old @MVC

Request Mapping Process

Designed to work with

different HandlerMapping types

E.g.

SimpleUrlHandlerMapping and others

Sounds reasonable but..

Back to the code

Back to the code

Back to the code

Back to the code

Other limitations of prior approach

New @MVC

A single point of decision

The code re-visited with 3.1

The code re-visited with 3.1

The code re-visited with 3.1

The code re-visited with 3.1

Other limitations lifted

Demo

spring-mvc-31-demo

Incidentally after the 3.1 release we had this ticket

SPR-9063

The code

The code

The code

The code with the new @MVC

Just remove the type-level HTTP method mapping

Is it not a regression?

The upgrade path

HandlerMethod:

An abstraction for various controller methods

How different method arguments are supported

to design your your own `@EnableXyz`

`@EnableWebMvc`

`@EnableWebMvc`

`WebMvcConfigurationSupport`

`DelegatingWebMvcConfigurationSupport`

`WebMvcConfigurationSupport`

Extending directly from `WebMvcConfigurationSupport`

The New
@MVC Support Classes

`DefaultAnnotationHandlerMapping`, `AnnotationMethodHandlerAdapter`, `AnnotationMethodExceptionResolver`

`RequestMappingHandlerMapping`, `RequestMappingHandlerAdapter`, `ExceptionHandlerExceptionResolver`

different `HandlerMapping` types

`SimpleUrlHandlerMapping`
and others

`HandlerMethod`:

Every built-in method argument has its own `HandlerMethodArgumentResolver`

Every supported return value has its own `HandlerMethodReturnValueHandler`

`RedirectAttributes` Example

Why not just use the `Model`?

How to enable use of `RedirectAttributes` for all redirects

Use `RedirectAttributes` for all redirects

`FlashMap`