The reason: Spring Boot is creating two application contexts when deploying it within tomcat servlet container, one WebApplicationContext with Tomcat listeners etc. and another WebApplicationContext with all beans. Furthermore the second context is set as parent to first context. Unfortunately Thymeleaf AuthUtils will get the first context, where they try to resolve the WebSecurityExpressionHandler bean, but the bean resolvement is not checking the parent context. (I don't know if this is a bug in bean resolvement in AuthUtils of Thymeleaf or if it's a Bug in Spring...)
Maybe a possible solution could be the following:
private static SecurityExpressionHandler<FilterInvocation> getExpressionHandler(final ServletContext servletContext) {
....
Map<String, SecurityExpressionHandler> expressionHandlers = ctx.getBeansOfType(SecurityExpressionHandler.class);
//if no SecurityExpressionHandlers have been found check if we have a parent context
if(expressionHandlers.isEmpty() && null != ctx.getParent()) {
expressionHandlers =
ctx.getParent().getBeansOfType(SecurityExpressionHandler.class);
}
...
}
Hi
Regaring the following thread: http://stackoverflow.com/questions/29706556/spring-boot-spring-security-tomcat-no-visible-websecurityexpressionhandler If creating a WAR file of a Spring-Boot application and deploying it to a Tomcat, after a new deployment or restart and accessing a template using Spring-Security Tags, the SecurityExpressionHandler will not be found. As I wote:
The reason: Spring Boot is creating two application contexts when deploying it within tomcat servlet container, one WebApplicationContext with Tomcat listeners etc. and another WebApplicationContext with all beans. Furthermore the second context is set as parent to first context. Unfortunately Thymeleaf AuthUtils will get the first context, where they try to resolve the WebSecurityExpressionHandler bean, but the bean resolvement is not checking the parent context. (I don't know if this is a bug in bean resolvement in AuthUtils of Thymeleaf or if it's a Bug in Spring...)
Maybe a possible solution could be the following: