Spring MVC Смешивание xml и java @ContextConfiguration в интеграционном тесте
Я пытаюсь настроить тест интеграции Spring MVC, используя комбинацию конфигурации XML и @Configuration аннотированные классы.
@RunWith(SpringJUnit4ClassRunner.class)
@WebAppConfiguration
@TestPropertySource({"/spring-security.properties",
"/rabbitmq-default.properties",
"/mongodb-default.properties",
"/webapp-override.properties"})
@ContextHierarchy({
@ContextConfiguration("classpath:**/security-config.xml"),
@ContextConfiguration(classes = RootConfig.class),
@ContextConfiguration(classes = SpringMvcConfig.class)
})
public class BaseConfiguredMvcIntegrationTest {
}
Конфигурации Java инициализируются правильно. Проблема в том, что "**/security-config.xml" файл найден и проанализирован во время инициализации... все определенные в нем компоненты безопасности Spring никогда не регистрируются в WebApplicationContext,
Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type [org.springframework.security.crypto.bcrypt.BCryptPasswordEncoder] found for dependency: expected at least 1 bean which qualifies as autowire candidate for this dependency. Dependency annotations: {@org.springframework.beans.factory.annotation.Autowired(required=true)}
at org.springframework.beans.factory.support.DefaultListableBeanFactory.raiseNoSuchBeanDefinitionException(DefaultListableBeanFactory.java:1301)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:1047)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:942)
at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.inject(AutowiredAnnotationBeanPostProcessor.java:533)
Поэтому мой вопрос: как использовать конфигурацию на основе XML и на основе аннотаций в тесте интеграции с MVC Spring?
Я мог бы изменить конфигурацию безопасности Spring на java/annoteted based... Я бы не хотел этого делать. Я считаю, что использование пространства имен spring security более читабельно и лаконично, чем использование конфигурации Java.
Также обратите внимание, что эта комбинированная конфигурация XML/Java прекрасно работает в не тестовой среде.
- Spring v4.1.6
- Spring Security v4.0.1
Конфигурация WebApplicationContext:
package com.gggdw.web.config;
import javax.servlet.FilterRegistration;
import javax.servlet.ServletContext;
import javax.servlet.ServletException;
import javax.servlet.ServletRegistration;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.WebApplicationInitializer;
import org.springframework.web.context.ContextLoaderListener;
import org.springframework.web.context.support.AnnotationConfigWebApplicationContext;
import org.springframework.web.filter.DelegatingFilterProxy;
import org.springframework.web.filter.HiddenHttpMethodFilter;
import org.springframework.web.servlet.DispatcherServlet;
@Configuration
public class GGGWebInitializer implements WebApplicationInitializer {
public static final String SERVLET_NAME = "ggg";
@Override
public void onStartup(ServletContext servletContext) throws ServletException {
// Create the 'root' Spring application context
AnnotationConfigWebApplicationContext rootContext = new AnnotationConfigWebApplicationContext();
rootContext.register(RootConfig.class);
// Manage the lifecycle of the root application context
servletContext.addListener(new ContextLoaderListener(rootContext));
// Create the dispatcher servlet's Spring application context
AnnotationConfigWebApplicationContext dispatcherContext = new AnnotationConfigWebApplicationContext();
dispatcherContext.register(SpringMvcConfig.class);
// Register and map the dispatcher servlet
ServletRegistration.Dynamic dispatcher = servletContext.addServlet(SERVLET_NAME, new DispatcherServlet(dispatcherContext));
dispatcher.setLoadOnStartup(1);
dispatcher.addMapping("/");
//Spring security config
FilterRegistration.Dynamic springSecurityFilterChain = servletContext.addFilter(
"securityFilter", new DelegatingFilterProxy("springSecurityFilterChain"));
springSecurityFilterChain.addMappingForServletNames(null, false, SERVLET_NAME);
//springSecurityFilterChain.setAsyncSupported(true);
servletContext.addFilter("hiddenHttpMethodFilter", HiddenHttpMethodFilter.class);
}
}
RootConfig.class
@Configuration
@Import({WebPropertiesConfig.class, // loads all properties files on class path from resources folder
MongoConfig.class // init mongodb connection
})
@ImportResource({"classpath:**/security-config.xml"}) // spring security xml config (java config not as readable)
public class RootConfig {
}
безопасности config.xml
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:security="http://www.springframework.org/schema/security"
xmlns:context="http://www.springframework.org/schema/context"
xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security.xsd
http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd">
<!-- <context:property-placeholder location="classpath:spring-security.properties" /> -->
<security:global-method-security pre-post-annotations="enabled" secured-annotations="enabled">
<security:expression-handler ref="expressionHandler"/>
</security:global-method-security>
<bean id="expressionHandler" class="org.springframework.security.access.expression.method.DefaultMethodSecurityExpressionHandler">
<property name="permissionEvaluator" ref="permissionEvaluator"/>
</bean>
<bean id="permissionEvaluator"
class="com.my.local.package.security.GenericPermissionEvaluator">
</bean>
<!-- Configure Spring Security -->
<security:http auto-config="true" use-expressions="true" >
<security:form-login login-page="${spring.security.login-page}"
login-processing-url="${spring.security.login-processing-url}"
default-target-url="${spring.security.default-target-url}"
authentication-failure-url="${spring.security.authentication-failure-url}"
username-parameter="${spring.security.username-parameter}"
password-parameter="${spring.security.password-parameter}"
/>
<security:logout logout-url="${spring.security.logout-url}"
logout-success-url="${spring.security.logout-success-url}" />
<security:intercept-url pattern="/**" requires-channel="https" />
<security:intercept-url pattern="/s/**" access="isAuthenticated()" requires-channel="https" />
<security:custom-filter ref="log4JMDCFilter" after="SECURITY_CONTEXT_FILTER"/>
<security:access-denied-handler error-page="${spring.security.access-denied-handler-error-page}" />
<!-- <security:session-management invalid-session-url="${spring.security.invalid-session-url}"/>
2 types of invalid session, brand new user and a timeout of a previous logged in user
both need to be handled differently -->
</security:http>
<bean id="customUserDetailsService" class="com.my.local.package.CustomUserDetailsService" depends-on="userRepository"/>
<bean id="bCryptPasswordEncoder" class="org.springframework.security.crypto.bcrypt.BCryptPasswordEncoder" />
<!-- log4j filter to add userName and ipAddress into logging on a per request/thread basis -->
<bean id="log4JMDCFilter" class="com.my.local.package.filter.Log4JMDCFilter"/>
<security:authentication-manager>
<security:authentication-provider user-service-ref="customUserDetailsService">
<security:password-encoder ref="bCryptPasswordEncoder"/>
</security:authentication-provider>
</security:authentication-manager>
</beans>
2 ответа
ОБНОВЛЕНИЕ: после дальнейшего рассмотрения и на основании ваших последних отзывов, поведение, которое вы испытываете, может быть результатом ошибки, которая была введена в Spring Framework 4.1.4 (подробнее см. SPR-13075).
Попробуйте перейти на Spring Framework 4.1.3 и дайте мне знать, если вы по-прежнему испытываете нежелательное поведение.
обратите внимание, что эта комбинированная конфигурация XML/Java прекрасно работает в не тестовой среде.
Как так?
Есть ли у вас буквально три (3) контекста, загруженных в иерархию в производстве?
Я сомневаюсь, что. Скорее, я предполагаю, что вы как-то загружаете один рут WebApplicationContext от "classpath:**/security-config.xml" а также RootConfig.class,
Таким образом, самый важный вопрос: как вы настраиваете корневой WebApplicationContext в работе?
Как только вы ответите на это, я могу рассказать вам, как добиться того же в вашей тестовой конфигурации.;)
С Уважением,
Сэм (автор Spring TestContext Framework)
Обратите внимание на примечание от PathMatchingResourcePatternResolver:
Обратите внимание, что "classpath*:" в сочетании с шаблонами в стиле Ant будет надежно работать только с хотя бы одним корневым каталогом до запуска шаблона, если только фактические целевые файлы не находятся в файловой системе. Это означает, что шаблон типа "classpath*:*. Xml" не будет извлекать файлы из корня файлов JAR, а только из корня расширенных каталогов. Это происходит из-за ограничения в методе JDK ClassLoader.getResources(), который возвращает местоположения файловой системы только для переданной пустой строки (указывая потенциальные корни для поиска).