No bean named 'springSecurityFilterChain' is defined=

SpringSecurity使用记录（五）-- 配置研究了好长时间，不知道从哪里下手。

新的版本，很多东西在网上找不到，只能看他们的文档，当然这些文档相当不错，就看是否耐心的研究了！总是有急躁的心理作祟，不能专心研读，却处处碰壁，效率上反而未达预期效果！终于，在无数次的沮丧下，稍微看到了点光亮！前面的文章太过皮毛，接下来的一些，希望能更加实际的，更加深入的分析每一个过程！一直通过默认配置进行设置：namespace(是security 3.0,网上也看到一些兄弟描述的是3.0，但是总是不符合我这里的namespace配置):<beans:beans xmlns="/schema/security"xmlns:beans="/schema/beans"xmlns:xsi="/2001/XMLSchema-instance"xsi:schemaLocation="/schema/beans /schema/beans/spring-beans-3.0.xsd/schema/security/schema/security/spring-security-3.0.xsd">按照默认配置的http（这是用来根据namespace设置的基本的security过滤器chain）：auto-config=true时，就相当于<http><form-login /><http-basic /><logout /></http>也就是使用了默认的过滤器。

我最开始的想法是能够把本地的login信息（不是调用spring security的login方法），传入到spring security的验证过滤器里面。

这里有一个比较关键的问题，就是封装他们的过滤器（或者仅仅是知道他们到底是哪些过滤器在起作用）：表1Alia s FilterClassNamespaceElementorAttributeCHA NNE L_FI LTE R ChannelProcessingFilterhttp/intercept-url@requires-channelCON CUR REN ConcurrentSessisession-management/concurrenT_S ESS ION _FIL TER onFiltercy-controlSECURI TY_ CON TEX T_FI LTE R Securi tyContextPersistenceFilterhttpLOGOUT _FIL TER LogoutFilterhttp/logoutX50 9_FI LTE R X509AuthenticationFilterhttp/x509PRE _AU TH_ FILT ER Astrac tPreAuthenticatedProcessingFilterSubc lassesN/ACAS _FIL TER CasAu thenti cationFilterN/AFOR M_L OGI N_F ILTE R UsernamePasswordAuthenticationFilterhttp/form-loginBAS IC_BasicAuthehttp/http-basicAUT H_F ILTE R nticati onFilt erSERVLE T_A PI_ SUP POR T_FI LTE R SecurityContextHolderAwareFilterhttp/@servlet-api-provisionREM EMB ER_ ME_ FILT ER RememberMeAuthenticationFilterhttp/remember-meANO NYM OUS _FIL TER AnonymousAuthenticationFilterhttp/anonymousSESSIO N_M ANA GEM ENT _FIL TER SessionManagementFiltersession-managementEXC EPTION_ TRA NSL ATI ON_ FILT ER ExceptionTranslat ionFilterhttpFILT ER_FilterSecurihttpSEC URI TY_I NTE RCE PTO R tyInte rcept orSWITCH _US ER_ FILT ER SwitchUserFilterN/A（最开始看的时候，把这个表格忽略了，现在看来这些就是我们想要的！）我们的验证过程，就是按照这样的顺序进行的。

SpringNoSuchBeanDefinitionException六⼤原因总结1. OverviewIn this article, we are discussing the Springorg.springframework.beans.factory.NoSuchBeanDefinitionException – this is a common exception thrown by the BeanFactory when trying to resolve a bean that simply isn’t defined in the Spring Context.We will discuss here the possible causes for this problem and the available solutions.2. Cause: No qualifying bean of type [...] found for dependencyThe most common cause of this exception is simply trying to inject a bean that isn’t defined. For example – BeanB is wiring in a collaborator – BeanA:1 2 3 4 5 6 7@Componentpublic class BeanA {@Autowiredprivate BeanB dependency; ...}Now, if the dependency – BeanB – is not defined in the Spring Context, the bootstrap process will fail with the no such bean definition exception:1 2 3 4org.springframework.beans.factory.NoSuchBeanDefinitionException:No qualifying bean of type[org.baeldung.packageB.BeanB] 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)}The reason is clearly indicated by Spring: “expected at least 1 bean which qualifies as autowire candidate for this dependency“One reason BeanB may not exist in the context – if beans are picked up automatically byclasspath scanning, and if BeanB is correctly annotated as a bean (@Component,@Repository, @Service, @Controller, etc) – is that it may be defined in a package that is not scanned by Spring:1 2 3package org.baeldung.packageB; @Componentpublic class BeanB { ...}While the classpath scanning may be configured as follows:1 2 3 4 5@Configuration@ComponentScan("org.baeldung.packageA") public class ContextWithJavaConfig {...}If beans are not automatically scanned by instead defined manually, then BeanB is simply not defined in the current Spring Context.3. Cause: No qualifying bean of type [...] is definedAnother cause for the exception is the existence of two bean definitions in the context, instead of one. For example, if an interface – IBeanB is implemented by two beans –BeanB1 and BeanB2:12 3 4 5 6 7 8@Componentpublic class BeanB1 implements IBeanB { //}@Componentpublic class BeanB2 implements IBeanB { //}Now, if BeanA autowires this interface, Spring will not know which one of the two implementations to inject:1 2 3@Component public class BeanA {34 5 6 7 @Autowiredprivate IBeanB dependency; ...}And again, this will result in a NoSuchBeanDefinitionException being thrown by theBeanFactory:1 2 3Caused by: org.springframework.beans.factory.NoUniqueBeanDefinitionException: No qualifying bean of type[org.baeldung.packageB.IBeanB] is defined: expected single matching bean but found 2: beanB1,beanB2Similarly, Spring clearly indicates the reason for the wiring failure: “expected single matching bean but found 2″.Notice however, that in this case, the exact exception being thrown is notNoSuchBeanDefinitionException but a subclass– theNoUniqueBeanDefinitionException. This new exception has been , for exactly this reason – to differentiate between the cause where no bean definition was found and this one – where several definitions are found in the context.Before this change, the exception above was:1 2 3Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type[org.baeldung.packageB.IBeanB] is defined: expected single matching bean but found 2: beanB1,beanB2One solution to this problem is to use the @Qualifier annotation to specify exactly the name of the bean we want to wire:1 2 3 4 5 6 7 8@Componentpublic class BeanA {@Autowired@Qualifier("beanB2")private IBeanB dependency; ...}Now Spring has enough information to make the decision of which bean to inject –BeanB1 or BeanB2 (the default nameof BeanB2 is beanB2).4. Cause: No Bean Named [...] is definedA NoSuchBeanDefinitionException may also be thrown when a bean that isn’t defined isrequested by name from the Spring context:1 2 3 4 5 6 7 8 9 10 11@Componentpublic class BeanA implements InitializingBean { @Autowiredprivate ApplicationContext context;@Overridepublic void afterPropertiesSet() {context.getBean("someBeanName");}}In this case, there is no bean definition for “someBeanName” – leading to the following exception:1 2Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'someBeanName'is definedAgain, Spring clearly and concisely indicates the reason for the failure: “No bean named X is defined“.5. Cause: Proxied BeansWhen a bean in the context is proxied using the JDK Dynamic Proxy mechanism, then the proxy will not extend the target bean (it will however implement the same interfaces).Because of this, if the bean is injected by an interface, it will be correctly wired in. If however the bean is injected by the actual class, then Spring will not find a bean definition that matches the class – since the proxy does not actually extend the class.A very common reason the bean may be proxied is the Spring transactional support – namely beans that are annotatedwith @Transactional.For example, if ServiceA injects ServiceB, and both services are transactional, injecting by the class definition will not work:1 2 3 4 5 6 7 8 9 10 11 12 13 14@Service@Transactionalpublic class ServiceA implements IServiceA{ @Autowiredprivate ServiceB serviceB;...}@Service@Transactionalpublic class ServiceB implements IServiceB{ ...}The same two services, this time correctly injecting by the interface, will be OK:1 2 3 4 5 6 7 8 9 10 11 12 13 14@Service@Transactionalpublic class ServiceA implements IServiceA{ @Autowiredprivate IServiceB serviceB;...}@Service@Transactionalpublic class ServiceB implements IServiceB{ ...}6. ConclusionThis tutorial discussed examples of the possible causes for the commonNoSuchBeanDefinitionException – with a focus on how to address these exceptions in practice.The implementation of all these exceptions examples can be found in – this is an Eclipse based project, so it should be easy to import and run as it is.。

CXF和spring整合遇到的问题：Nobeannamedcxfisdefined
今天在做ws和spring整合的时候，很不幸的遇到了这个问题，百度了好久，竟然没⼈遇到这个问题，后来⾕歌了⼀下，都是遇到这个问题的了。

在看到⼀篇⽂章中提到了cxf.xml，所以我果断的打开这个配置⽂件看了⼀下，有⼀个很关键的地⽅：
<bean id="cxf"class="org.apache.cxf.bus.spring.SpringBus" destroy-method="shutdown"/>
哦，原来这个bean在这⾥定义的，那应该就是这个⽂件没导⼊到我们的spring⽂件中去了。

后来仔细⼀看，发现⾃⼰的ws的spring配置⽂件没被扫描==！。

好像⾼版本的spring会⾃动加载这⼏个⽂件的。

如果没有加载的话，那么我们就⼿动加载：
<!-- 引cxf的⼀些核⼼配置 -->
<import resource="classpath:META-INF/cxf/cxf.xml" />
<import resource="classpath:META-INF/cxf/cxf-extension-soap.xml" />
<import resource="classpath:META-INF/cxf/cxf-servlet.xml" />
其中，我们遇到问题的那个就是在‘cxf.xml’中。

spring配置xml遇到的问题——nobeannamedxxxavailable跟着慕课⽹的免费课打算加强⾃⼰对于spring的理解，结果第⼀步在spring配置bean的xml就遇到了问题，感觉名字什么的都是对的，但是就是⼀直报no bean named 'xxx' available这个错，也不知道为什么。

这个错误的意思是没有叫xxx这个名字的bean可获得。

根据这个提⽰我思考了⼀下可能的问题。

1.xml这个bean的id的命名和我应⽤时写的要获取的名字不⼀样。

（排除）2.xml这个bean的class路径不对。

（排除）3.实际上这个xml没有获取到。

（是的）最后发现的确是这个xml没有获取到，其实控制台没有显⽰Loading XML bean definitions from URL 就应该能看出来，但是还是忽略了这个信息找了很久的原因。

原因找到了但是为什么没有找到这个xml呢。

我⽤的是classpath*:spring-dao.xml去获取的spring-dao.xml这个⽂件，应该是去bin⽬录下的根⽬录找的，但是bin的根⽬录下不存在这个⽂件，可能是我⽂件的层级设置出了问题，⽂件夹和package的设置出了点问题，导致spring-dao.xml编译到bin的时候不是在根⽬录⽽是在⾥⾯⼏层的⽂件夹⾥。

这个博客解释了⼀下eclipse 下⾯的folder，source folder，package的区别与作⽤，“所以就设计出来⼀个特别的⽂件夹叫source folder，放在他下⾯的java⽂件就能被编译，⽽且，可以通过⼀定的配置将编译⽂件放在你配置的⽂件夹下⾯”，这个说明了从哪⼀层级的编译到bin或者classes⽂件中去。

也就是要将哪⼀层⾥的东西开始编译到⽬录⾥去，就把哪⼀层的⽂件夹设为source folder，我暂时是这么理解的。

记⼀次Nobeannamedorg.springframework.context.ann。

零、先抛结论该异常抛出只是连锁反应的⼀环，是表象结果⽽不是根本原因，追着⽇志向上查spring是否之前就抛出了其他异常。

⽽正是这些更早的异常导致spring不能符合预期的⼯作。

⼀、现象 服务可以正常启动，在调⽤某些服务的时候必抛出如下异常。

google查找若⼲，多数情况下是启动时报错，⽽不是运⾏时，所有未找到契合的先例。

测试等了半天问啥时候可以解决，只能硬着头⽪说，先绕过观察下其他⽤例是否正常，正是其他⽤例暴露出了bug的尾巴。

org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'myBean'defined in .my.BeanContainer: BeanPostProcessor before instantiation of bean failed;nested exception is org.springframework.beans.factory.BeanCreationException:Error creating bean with name 'org.springframework.cache.annotation.ProxyCachingConfiguration':Initialization of bean failed; nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException:No bean named 'org.springframework.context.annotation.ConfigurationClassPostProcessor.importRegistry' available⼆、bug的尾巴这个狐狸的尾巴正是下⾯这个异常，说明springContext有问题啊，异常说没有refresh，那是不是applicationContext.refresh()抛异常了呢。

web项目从tomcat移植到websphere6.1提示“no bean named..."的错误这几天搞一个小项目，本地环境采用jdk1.6和tomcat，本地运行完全正常，但是发布到websphere 6.1后，奇怪的问题出现了，访问页面一直提示错误：[11/21/11 11:47:52:358 CST] 0000009c E UOW=nullsource=com.ibm.ws.webcontainer.webapp .WebApp org=IBM prod=WebSphere component=Application Serverthread=[WebContainer : 6][ServletError]-[/grade_step.jsp]:org.springframework.beans.factory.NoS uchBeanDefinitionException: No bean named 'sessionFactory' is definedatorg.springframework.beans.factory.sup port.DefaultListableBeanFactory.getBe anDefinition(DefaultListableBeanFactory.java:387)atorg.springframework.beans.factory.sup port.AbstractBeanFactory.getMergedLoc alBeanDefinition(AbstractBeanFactory. java:971)atorg.springframework.beans.factory.sup port.AbstractBeanFactory.doGetBean(Ab stractBeanFactory.java:246).....以为是程序的原因，于是分别在tomcat5.5和tomcat6下面都试着部署了，都是正常的，然后在网上到处搜索了一下，发现也有人遇到过类似的问题，但是解决办法都描述得不清晰，有人说可能是spring配置的通配符问题，于是我也试着把这些配置修改为详细的列表，居然正常了。

spring security学习笔记-----每天进步一点点一、acegi security2.0 普通配置方法1、spring-security配置<?xml version="1.0" encoding="UTF-8"?><beans xmlns="/schema/beans"xmlns:xsi="/2001/XMLSchema-instance"xsi:schemaLocation="/schema/beans/schema/beans/spring-beans-2.0.xsd" ><!-- 设置过滤器链，按顺序过滤 --><bean id="filterChainProxy"class="org.acegisecurity.util.FilterChainProxy"><property name="filterInvocationDefinitionSource"><value>CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISONPATTERN_TYPE_APACHE_ANT/**=sessionIntegrationFilter,logoutFilter,authenticationFilter,anonym ousProcessingFilter,exceptionFilter,securityInterceptor</value></property></bean><!--认证管理器 --><bean id="authenticationManager"class="org.acegisecurity.providers.ProviderManager"><property name="providers"><list><!-- <ref bean="daoAuthenticationProvider" />--><ref local="anonymousAuthenticationProvider"/></list></property></bean><bean id="loggerListener"class="org.acegisecurity.event.authentication.LoggerListener"/> <!-- 基于DAO验证的AuthenticationProvider --><bean id="daoAuthenticationProvider"class="org.acegisecurity.providers.dao.DaoAuthenticationProvider"><property name="userDetailsService" ref="userDetailsService" /> </bean><bean id="anonymousAuthenticationProvider"class="org.acegisecurity.providers.anonymous.AnonymousAuthenticationP rovider"><property name="key" value="anonymous"/></bean><!-- 测试用service 实际中使用Daoservice替代 --><bean id="userDetailsService"class="com.myhoel.security.HotelUserDetailService"><property name="accountDao"><ref bean="accountDao"/></property></bean><!-- 决策管理器， --><bean id="accessDecisionManager"class="org.acegisecurity.vote.AffirmativeBased"><property name="decisionVoters"><list><bean class="org.acegisecurity.vote.RoleVoter" /></list></property><property name="allowIfAllAbstainDecisions" value="false" /> </bean><!--位于过滤器顶端，第一个起作用的过滤器用途一，在执行其他过滤器之前，率先判断用户的session中是否已经存在一个SecurityContext了。

spring security 11种过滤器介绍1.HttpSessionContextIntegrationFilter位于过滤器顶端，第一个起作用的过滤器。

用途一，在执行其他过滤器之前，率先判断用户的session中是否已经存在一个SecurityContext了。

如果存在，就把SecurityContext拿出来，放到SecurityContextHolder中，供Spring Security的其他部分使用。

如果不存在，就创建一个SecurityContext出来，还是放到SecurityContextHolder中，供Spring Security的其他部分使用。

用途二，在所有过滤器执行完毕后，清空SecurityContextHolder，因为SecurityContextHolder是基于ThreadLocal的，如果在操作完成后清空ThreadLocal，会受到服务器的线程池机制的影响。

--------------------------------------------------------------------------------------------2.LogoutFilter只处理注销请求，默认为/j_spring_security_logout。

用途是在用户发送注销请求时，销毁用户session，清空SecurityContextHolder，然后重定向到注销成功页面。

可以与rememberMe之类的机制结合，在注销的同时清空用户cookie。

--------------------------------------------------------------------------------------------3.AuthenticationProcessingFilter处理form登陆的过滤器，与form登陆有关的所有操作都是在此进行的。

默认情况下只处理/j_spring_security_check请求，这个请求应该是用户使用form登陆后的提交地址，form所需的其他参数可以参考：此过滤器执行的基本操作时，通过用户名和密码判断用户是否有效，如果登录成功就跳转到成功页面（可能是登陆之前访问的受保护页面，也可能是默认的成功页面），如果登录失败，就跳转到失败页面。

SpringSecurity（2）：过滤器链（filterchain）的介绍上⼀节中，主要讲了Spring Security认证和授权的核⼼组件及核⼼⽅法。

但是，什么时候调⽤这些⽅法呢？答案就是Filter和AOP。

Spring Security在我们进⾏⽤户认证以及授予权限的时候，通过各种各样的拦截器来控制权限的访问。

对于基于HttpRequest的⽅式对端点进⾏保护，我们使⽤⼀个Filter Chain来保护；对于基于⽅法调⽤进⾏保护，我们使⽤AOP来保护。

本篇重点讲Spring Security中过滤器链的种类及过滤器中如何实现的认证和授权。

Spring Security会默认为我们添加15个过滤器，我们可以从WebSecurity（WebSecurity是Spring Security加载的⼀个重要对象，将在下节具体讲述）的performBuild()⽅法中看到过滤器链SecurityFilterChain的构建过程，并交由FilterChainProxy对象代理。

我们从SecurityFilterChain的默认实现类DefaultSecurityFilterChain中的log看出，Spring Security由以下过滤器组成了过滤器链：Creating filter chain: any request, [org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter@7f353a0f,org.springframework.security.web.context.SecurityContextPersistenceFilter@4735d6e5,org.springframework.security.web.header.HeaderWriterFilter@314a31b0,org.springframework.security.web.csrf.CsrfFilter@4ef2ab73,org.springframework.security.web.authentication.logout.LogoutFilter@57efc6fd,ernamePasswordAuthenticationFilter@d88f893,org.springframework.security.web.authentication.ui.DefaultLoginPageGeneratingFilter@2cd388f5,org.springframework.security.web.authentication.ui.DefaultLogoutPageGeneratingFilter@7ea2412c,org.springframework.security.web.authentication.www.BasicAuthenticationFilter@2091833,org.springframework.security.web.savedrequest.RequestCacheAwareFilter@4dad0eed,org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter@16132f21,org.springframework.security.web.authentication.AnonymousAuthenticationFilter@1c93b51e,org.springframework.security.web.session.SessionManagementFilter@59edb4f5,org.springframework.security.web.access.ExceptionTranslationFilter@104dc1a2,org.springframework.security.web.access.intercept.FilterSecurityInterceptor@1de0641b]下⾯就是各个过滤器的功能，其中SecurityContextPersistenceFilter，UsernamePasswordAuthenticationFilter及FilterSecurityInterceptor分别对应了上节SecurityContext，AuthenticationManager，AccessDecisionManager的处理。

JavaSpringSecurity常见面试题目Java Spring Security常见面试题目1. 什么是Spring Security？Spring Security是一个功能强大且高度可定制的认证和授权框架，用于保护Java应用程序的安全性。

它提供了一套全面的安全性功能，包括身份验证、授权、密码管理、会话管理等，以确保应用程序的数据和资源得到适当的保护。

2. Spring Security的主要特点有哪些？- 身份验证和授权：Spring Security提供了多种身份验证方式，如基于用户名密码的表单验证、基于OpenID的身份验证等，并支持基于角色或权限的访问控制。

- 集成简化：Spring Security能够与Spring框架无缝集成，通过简单的配置即可启用安全性功能。

- 定制化：Spring Security提供了丰富的扩展点和配置选项，可以根据应用程序的需求进行灵活的定制。

- 高度模块化：Spring Security的架构设计具有高度模块化的特点，不同的功能模块可以根据需求进行选用和定制。

- 支持多种应用场景：Spring Security适用于各种应用场景，包括Web应用、RESTful服务、方法级安全等。

3. Spring Security是如何进行身份验证的？Spring Security提供了多种身份验证方式，常见的一种是基于表单的身份验证。

在这种情况下，用户通过输入用户名和密码提交表单进行身份验证，Spring Security会将提交的用户名和密码与事先配置的用户存储库（如数据库）进行比对。

如果用户名和密码匹配，则认为身份验证成功，并生成相应的认证令牌。

4. Spring Security如何进行授权？Spring Security支持基于角色和基于权限的访问控制。

在配置中，可以指定某个URL或某个方法只能被具有特定角色或权限的用户访问。

在运行时，Spring Security会根据当前用户的角色和权限，判断其是否具有访问相应资源的权限。