Spring 3 MVC naming gotcha

As the title suggests, I got bitten by a naming issue in Spring 3 (3.0.5) MVC. I wasted a fair amount of time on it, so I don't want to do it again. The relevant material pertaining to this issue may be in the Spring reference documentation however hopefully this blog post will be more concise for anybody else who has had this problem.

In my MVC app I have a ProductsSearcher class that has two dependencies that are injected via the constructor. In my Spring config XML I have the following snippets:

<context:component-scan base-package="org.myproject" />

<bean class="org.myproject.ProductsSearcher"> ... </bean>

The component-scan tag is needed to get Spring to process the @Controller annotation to get the bean registered as a MVC controller However when boot strapping the application context the deployment failed

ERROR [DispatcherServlet] Context initialization failed
org.springframework.beans.factory.BeanCreationException: Error
creating bean with name 
'org.springframework.web.servlet.mvc.annotation.
DefaultAnnotationHandlerMapping#0': Initialization of bean
failed; nested exception is org.springframework.beans.
factory.BeanCreationException: Error creating bean with
name 'productsSearcher' ... Instantiation of bean failed;
nested exception is org.springframework.beans.
BeanInstantiationException: Could not instantiate bean class [org.
myproject.ProductsSearcher]: No default constructor
found; nested exception is java.lang.NoSuchMethodException: org.
myproject.ProductsSearcher.()

So Spring was trying to instantiate an instance of my class via reflection and borking because there was no default constructor on the class. Why would it do that when I have a bean definition in the config?

I wasn't willing to change the constructor because, good design dictates that if the class can't function without a dependency then the dependency must be injected at construction time; otherwise the object will be in an illegal state (not "fully formed").

I thought it might be something to do with the component scanning as component scanning also involves processing configuration annotations (a good discussion of the XML tags that deal with annotation processing can be found on Stack Overflow.).

The problem lies in the name/id (or lack thereof) of the bean instance. Component scanning does involve Spring creating an instance of the stereotype (ie: my @Controller) but the instance was created with a given name. Given the good old Java Bean naming conventions the name is productsSearcher. By default whenever I create stereotyped bean config I give the bean this style of name. This time I forgot :( :(. Adding in the id fixed the deployment issue

<bean id="productsSearcher" class="org.myproject.ProductsSearcher"> ... </bean>
... </bean>

So my bean definition overrides the default and the correct bean definition is used and the bean is instantiated.

Given that most of us would name our beans using the Java Beans naming convention (since as Spring users it's been beaten into us) this problem had never occurred to me. If anybody has any insight into the workings of the Spring mechanisms behind component scanning please offer up your wisdom in the comments. For the rest of us, remember to name your stereotyped beans properly.