context depended scan-component filter

My SpringMVC based webapp uses typically 2 contexts: the webapplication context for the MVC dispatcher servlet and the parent/root application context.

<!-- the context for the dispatcher servlet -->
<servlet>
    <servlet-name>webApp</servlet-name>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
    <init-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>classpath*:servlet-context.xml</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
</servlet>
....
<!-- the context for the root/parent application context -->
<context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>classpath*:root-context.xml</param-value>
</context-param>

Within these contexts, I use component scanning for loading all beans. My packages are named according their usecase (e.g. com.abc.registration, com.abc.login etc.) rather then based on the technological tier (e.g. com.abc.dao, com.abc.services etc.)

Now my question: in order to avoid duplicate scanning of some classes, is it a good practice, to filter the candidate component classes for both contexts, e.g. include only the MVC Controller for web context scan and include all other components (services, dao/repositorie) in the root application context ?

<!-- servlet-context.xml -->
<context:co开发者_JS百科mponent-scan base-package="com.abc.myapp" use-default-filters="false">
    <context:include-filter type="annotation" expression="org.springframework.stereotype.Controller"/>
</context:component-scan>

<!-- root-context.xml -->
<context:component-scan base-package="de.efinia.webapp">
    <context:exclude-filter type="annotation" expression="org.springframework.stereotype.Controller"/>
</context:component-scan>

Or is it neither important nor necessary to avoid such duplication for the component scan ?

I like your solution in two areas:

1. You divide classes based on uses cases rather than layers. If you would have a single web package with all controllers then you wouldn't have problems. But still I found such an approach much better.

2. Yes, you should filter classes. Obviously it's not a problem with increased memory footprint, as this is marginal (but increased startup time might be significant).

However having duplicated beans (both controllers and service beans) might introduce subtle bugs and inconsistencies. Some connection pool has been initialized two times, some startup hook runs two times causing unexpected behavior. If you use singleton scope, keep that it way. Maybe you won't hit some problems immediately, but it's nice to obey the contracts.

BTW note that there is an <mvc:annotation-driven/> tag as well.

It is a good practice, indeed. The parent application context should not have controllers in it.

I can't add more arguments to justify the practice, but it certainly is cleaner that way.