Spring support for @Controller given by <context:component-scan /> vs <mvc:annotation-driven>

Question

I've been researching what additional capabilities we have when using the mvc:annotation-driven tag and I'm having a difficult time digesting the results, especially in regards to the @Controller annotation. I know this is very similar to this question but please hear me out.

According to the Spring docs

The basic purpose of the @Controller annotation is to act as a stereotype for the annotated class, indicating its role. The dispatcher will scan such annotated classes for mapped methods, detecting @RequestMapping annotations (see the next section).

The documentation then goes on to show that the context:component-scan tag provides this support. So that's all well and good, but then I was looking at what mvc:annotation-driven gives us, and the aforementioned stackoverflow question provides the following answer

mvc:annotation-driven declares explicit support for annotation-driven MVC controllers (i.e. @RequestMapping, @Controller, although support for those is the default behaviour), as well as adding support for declrative validation via @Valid and message body marshalling with @RequestBody/ResponseBody.

This seems kind of redundant to me. Maybe I don't get what this explicit support is. Again, referring back to the official Spring documentation we get the following

[mvc:annotation-driven] registers the DefaultAnnotationHandlerMapping and AnnotationMethodHandlerAdapter beans that are required for Spring MVC to dispatch requests to @Controllers.

That sounds pretty similar to the last example I provided from the docs. If anyone can provide some examples as to what we can do with the @Controller annotation using only the context:component-scan tag, what some of the limitations are, then the additional functionality of what we get when adding the mvc:annotation-driven tag, I think that would be very helpful. Thanks in advance for any support on this.

Answer 1

Both elements serve an entirely different purpose.

<context:component-scan /> is, as the name implies, for component scanning. It by default scans for all beans with the @Component annotation (or "sub"annotations like @Controller, @Service etc.). It will only register instances of those classes in the application context as beans. That is all.

<mvc:annotation-driven /> is for bootstrapping Spring MVC and it registers, amongst others, a RequestMappingHandlerMapping and RequestMappingHandlerAdapter. The first links requests to a certain method (the @RequestMapping annotation on methods in a @Controller annotated class). The last knows how to execute methods annotated with @RequestMaping.

Now <mvc:annotation-driven /> does nothing for scanning or detecting @Controllers if there are none in the application context then no request mappings are made. Now you have several ways of registering those beans in the application context and one of them is the aforementioned <context:component-scan />.

Basically a @Controller without <mvc:annotation-driven /> is, well, pretty useless as it does nothing but take up memory. It will not be bound to incoming requests, it just hangs around in the application context. It is just another bean like all other beans and nothing special is being done to it. (Recent, but deprecated, versions of Spring register the DefaultAnnotationHandlerMapping which processes the @Controller, this is however deprecated).

Answer 2

The context:component-scan element lists a package that Spring should scan for @Controller annotations (in the base-package attribute).

the mvc:annotation-driven has no such attribute. This is a convenience element that installs a lot of default MVC elements into the application context. These elements are listed in section 16.14.1 of the Spring framework reference. This element does not appear to scan for @Controller annotations.

Contrary to popular belief, there is no dependancy between these elements. An @Controller without mvc:annotation-driven will function without an issue and handle HTTP requests just fine, as long as you have included context:component-scan with an appropriate base-package attribute.