2017  Kodetalk | Feedback | Privacy Policy | Terms | About
userimage

@Service are constructed twice

I have a problem with my Spring application where my @Service classes are being created twice when the application starts. I know this is a problem with my configuration, as I"ve experienced it before, but what exactly am I doing wrong?

Is there anything fundamentally wrong with the way I"ve laid out my config, below? (I have omitted everything I deem to be irrelevant)


myapp-servlet.xml

<context:component-scan base-package="com.myapp" annotation-config="true" />
<mvc:annotation-driven />

myapp-config.xml

<context:component-scan base-package="com.myapp" annotation-config="true" />

<context:annotation-config />
userimage

solution for this problem:
myapp-config.xml:
<!-- Load everything except @Controllers -->

<context:component-scan base-package="com.myapp">   

<context:exclude-filter expression="org.springframework.stereotype.Controller"        type="annotation"/>

</context:component-scan>

myapp-servlet.xml:
<!-- Load @Controllers only -->

<context:component-scan base-package="com.myapp" use-default-filters="false">   

<context:include-filter expression="org.springframework.stereotype.Controller"         type="annotation"/>

</context:component-scan>

EDIT:
Removing <context:component-scan> from myapp-config.xml means that all your autodiscovered annotated beans are registered in DispatcherServlet's context (that is, the context loaded from myapp-servlet.xml). However the recommended approach is to use servlet's context for presentation-specific things (such as controllers), and use the root context (myapp-config.xml) for the core services of your application. The solution above make this approach easy.
Regarding the practical considerations, when your core services are placed in servlet's application context, they can't be accessed from outside the scope of that servlet, for example, from another servlets (you may need to use another servlets to implement another access technologies) or filters (such as Spring Security filters). That's the reason for having core services in the root application context.

Answer is