I read about the difference between a web context and an application context. It seems to understand the difference, but constantly stumble on a rake. In the deployment descriptor, the specified context configurations

<context-param> <param-name>contextConfigLocation</param-name> <param-value>/WEB-INF/spring/root-context.xml</param-value> </context-param> <servlet> <servlet-name>appServlet</servlet-name> <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class> <init-param> <param-name>contextConfigLocation</param-name> <param-value>/WEB-INF/spring/servlet-context.xml</param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet> 

In servlet-context.xml I tried to leave only the presentation layer

 <context:component-scan base-package="com.example"> <context:include-filter type="annotation" expression="org.springframework.stereotype.Controller"/> </context:component-scan> 

In root-context.xml, on the contrary, I want to load everything except controllers.

 <context:component-scan base-package="com.example"> <context:exclude-filter type="annotation" expression="org.springframework.stereotype.Controller"/> </context:component-scan> 

and by importing I connect the configuration of the data access layer, transactions, security, cache, etc.

Only the @Transactional annotation, for example, refuses to work in the service layer until I put the <tx:annotation-driven transaction-manager="transactionManager"/> in the servlet-context.xml. That is, bins marked with annotations @Service and @Repository somehow loaded into the web context? Why is that? Or do I still misunderstand the difference between contexts?

    1 answer 1

    The <context:component-scan> configuration by default searches for classes located in base-package and nested packages and annotated with @Component (and all its descendants are @Service , @Repository , @Controller , etc.). The <context:include-filter> and <context:exclude-filter> elements only expand or narrow the search criteria, not replace it.

    Configuration

     <context:component-scan base-package="com.example"> <context:include-filter type="annotation" expression="org.springframework.stereotype.Controller"/> </context:component-scan> 

    will force Spring to search in the com.example package com.example classes marked with the @Component annotation, as well as classes marked with the org.springframework.stereotype.Controller annotation.

    To prevent Spring from looking for default annotations, add the use-default-filters="false" attribute to the configuration:

     <context:component-scan base-package="com.example" use-default-filters="false"> <context:include-filter type="annotation" expression="org.springframework.stereotype.Controller"/> </context:component-scan> 

    Now Spring will only search for classes marked with the @Controller annotation.

    In your configuration, the com.example package was completely scanned in both contexts (in root-context , with the exception of controllers). The service layer beans were first created in the root-context (and transaction management was enabled for them), and then again in the servlet-context (transaction management was not enabled for them). When Spring looks for dependencies in order to embed them in bins, it first searches for them in the current context (for controllers, this is servlet-context ), and if it does not, in the parent root-context . Since you found the necessary classes in the servlet-context , Spring was not useful in the root-context , and the controllers injected the bins without transaction management.

    • Does the include-filter parameter not narrow the criteria for the loaded bins only to those specified in it? - Hivemaster
    • Does not narrow. On the contrary, in the absence of use-default-filters="false" , it extends the default criteria used. - fori1ton 1:56 pm
    • I did not find the XML configuration documentation, but I found an analogue in the Java configuration. Its documentation is clearly spelled out. Spring is a fairly consistent framework, so it can be expected that similar parameters will behave the same in XML and in Java configuration. - fori1ton
    • It is interesting! I will try and accomplish your goal. - Hivemaster
    • Thank you so much, it works! - Hivemaster 2:46 pm