设置了 scanPeriod 之后，过了好长时间，都不生效，后来 debug 代码。发现了下面这段。

  private volatile long mask = 0xF;
@Override
public FilterReply decide(Marker marker, Logger logger, Level level,
String format, Object[] params, Throwable t) {
if (!isStarted()) {
return FilterReply.NEUTRAL;
}
// for performance reasons, skip change detection (MASK-1) times out of MASK.
// Only once every MASK calls is change detection code executed
// Note that MASK is a variable itself.
if (((invocationCounter++) & mask) != mask) {
return FilterReply.NEUTRAL;
}
long now = System.currentTimeMillis();
synchronized (configurationWatchList) {
updateMaskIfNecessary(now);
if (changeDetected(now)) {
// Even though reconfiguration involves resetting the loggerContext,
// which clears the list of turbo filters including this instance, it is
// still possible for this instance to be subsequently invoked by another
// thread if it was already executing when the context was reset.
disableSubsequentReconfiguration();
detachReconfigurationToNewThread();
}
}
return FilterReply.NEUTRAL;
}

这行 if (((invocationCounter++) & mask) != mask) { mask = 0xf，其实要每循环 0xf 次，也就是 15 次，才会去 check 一次是否要更新，也就是说，不管过了多久，如果没到这 15 次，也不会去检查是否更新配置。
也就是说，我多打几次 log，配置文件就生效了。

spring security（下简写为 ss）控制的安全主要有两方面，Web 和 Method Call，这两个方面的权限控制有比较多的相通的设计，也有一些特别的功能。比如 Method Call 可以做 After Invocation 控制，而 Web 可以做 Ip 地址控制。

这里面有两个最基本的概念：authentication manager 和 access decision manager，前者控制认证，后都控制鉴权。
1. 在 ss 的认证系统中，默认的实现帮助我们提供了三个概念，用户（user），角色（authority，一般存 role）和组（group），三者的关系是，组、角色与用户都是多对多关系，组和角色间没关系，默认是不启用组的。后续，在 Acl 权限管理中，可以看到角色之间，是可以有包含（树形？）关系的。
2. 在 ss 的鉴权系统中，明显会比认证复杂得多。有 AccessDecisionManager, AccessDecisionVoter（前置）, AfterInvocationProvider（后置）, RoleHierarchy, SidRetrievalStrategy, LookupStrategy, PermissionGrantingStrategy, SecurityExpressionHandler, AclService, MutableAclService, AclCache 概念过多了，要一个一个解释
a) 中心是 AccessDecisionManager，主要负责 AccessDecisionVoter 的管理，默认提供了3种实现：1. AffirmativeBased 如果有任何一个投票器允许访问,请求将被立刻允许,而不管之前可能有的拒绝决定。2. ConsensusBased 多数票(允许或拒绝)决定了结果，平局的投票 和空票(全是弃权的)的结果是可配置的。3. UnanimousBased 所有的投票器必须全是允许的,否则访问将 被拒绝。
AccessDecisionManager 在用于 Web 和 Method Call 两种情况下，可能是不一致的，因为功能也不一致。
b) Method Call 除了使用 AccessDecisionManager 进行权限判断外，还可以增加 AfterInvocationProvider 来进行出口数据的判断，默认提供了 3 种。
1) PostInvocationAdviceProvider: 需要提供一个 PostInvocationAuthorizationAdvice，默认实现只有一个，就是 ExpressionBasedPostInvocationAdvice，可以通过 spel 来进行权限判断。注意 ExpressionBasedPostInvocationAdvice 中需要提供一个 MethodSecurityExpressionHandler，能够创建出一个 MethodSecurityExpressionOperations，放到 spel context 中，供 spel function 调用，这样的方式，在后续很常见。
2) AclEntryAfterInvocationProvider 和 AclEntryAfterInvocationCollectionFilteringProvider : 这两种都差不多，主要依赖 AclService, ObjectIdentityRetrievalStrategy, SidRetrievalStrategy 来配合，检查返回值的权限。Collection 版本的，可以把无权限的数据去掉，只留下有权限的数据。
c) RoleHierarchy 提供了角色之间的关系，提供了两个实现，一个是没关系的，直接把 user 的 role 返回，另外一个是有继承关系的。继承关系实现挺有意思的，能够处理多级的 include 关系，比较好用。
RoleHierarchy 的使用比较复杂，会被 AccessDecisionVoter, SidRetrievalStrategy, SecurityExpressionHandler 用到，SecurityExpressionHandler 又会被 AccessDecisionVoter 用到，所以还是有点儿混乱。
具体的说 SecurityExpressionHandler 会用到 PermissionEvaluator 和 RoleHierarchy，PermissionEvaluator 的一个实现 AclPermissionEvaluator 会用到 SidRetrievalStrategy。
d) SidRetrievalStrategy 和 RoleHierarchy 的功能比较接近，比 RoleHierarchy 高一个抽象层次，功能上也有所区别，是从一个 authentication 拿到所有相关的 Sid（包括 Role（GrantedAuthoritySid） 和 User（PrincipalSid）），而 RoleHierarchy 只包括了 Role（GrantedAuthoritySid）的继承关系。
e) LookupStrategy 通过 ObjectIdentity 和 Sid 把相关的 Acl 查询出来。可以在 LookupStrategy 扩展 Acl 和 Ace 的功能，比如在 Ace 上面加上时间的条件限制，就需要自己定义 LookupStrategy，把时间条件从数据库查询出来，并放到自定义的 Ace 当中。
但这件事情非常麻烦，因为默认实现的 BasicLookupStrategy 是个 Final 的类，所以只能自己直接实现接口，无法使用现有的功能。
LookupStrategy 会生成 Acl，而最终的权限验证是由 Acl 完成的，如果想验证带时间条件的 Ace，需要给 Acl 设置自定义的带有检查时间功能的 PermissionGrantingStrategy，实际上，这个 PermissionGrantingStrategy 会首先设置给 LookupStrategy，LookupStrategy 在创建 Acl 的时候，再放到 Acl 中去。
f) SecurityExpressionHandler 能够执行 spel，得到是否可以访问的结果，它的子类都是继承自 AbstractSecurityExpressionHandler 的，有一个非常重要的方法是 SecurityExpressionOperations createSecurityExpressionRoot(Authentication authentication, T invocation)，创建一个 SecurityExpressionOperations 放到 EvaluationContext 中去，提供 spel 中执行的方法实现。比如 SecurityExpressionOperations 的一个抽象实现 SecurityExpressionRoot 中，就包含了大量的权限验证方法，如 hasRole, hasPermission 等常用的功能。
g) AclService, MutableAclService, AclCache 概念比较简单，AclService 是通过 LookupStrategy 查询 Acl，自已可以查询 ObjectIdentity 的父子关联关系，MutableAclService 提供了修改的能力，AclCache 为 AclService 提供缓存，默认的实现了一个 EhCacheBasedAclCache。
3. ss 的鉴权模型 Sid, ObjectIdentity, Acl, Ace, Permission
a) Sid: 是中心，所有的授权会关联在 Sid 上面，Sid 和之前的 Role Base Permission 会有些相同的地方，但也明显不同，Sid 默认实现情况下，分为 GrantedAuthoritySid 和 PrincipalSid，其实就是 Role 和 User，通过 SidRetrievalStrategy 拿到一个 Authentication 的 Sid。
b) ObjectIdentity: 可以理解成 Resource，就是可访问的目标资源，有 id 和 type 两个字段，默认实现的 ObjectIdentityImpl 会直接调用目标 domainObject 的 getClass 和 getId 方法拿到两个参数。在 PermissionEvaluator, AfterInvocationProvider 中，会用到 ObjectIdentityRetrievalStrategy 和 ObjectIdentityGenerator，ObjectIdentityRetrievalStrategy 会根据 domainObject 拿到 ObjectIdentity，然后使用 Acl 进行鉴权，ObjectIdentityGenerator 会在系统提供的不是 domainObject，而是 type, id 的时候，拿到 ObjectIdentity，然后进行 Acl 鉴权，这两个接口有一个共同的实现 ObjectIdentityRetrievalStrategyImpl，如果需要在 ObjectIdentity 进行新的抽象，需要用新的实现，到得不同的 ObjectIdentity，比如将业务对象分类鉴权这样的需求。
c) Acl, 每个 ObjectIdentity 最多对应一条 Acl，Acl 中包含了很多，包括 parental，说明 Acl 是有继承关系的？其实不是，呵呵，是 ObjectIdentity 有继承关系而已。有一个 ObjectIdentity，有很多 Sid，还有一个叫做 Owner 的 Sid，有从 LookupStrategy 传过来的 PermissionGrantingStrategy，进行实际的鉴权，还有 AclAuthorizationStrategy 检查有没有权限进行 Acl security check。实现时间条件检查，就扩展 PermissionGrantingStrategy。
为什么没有 RoleHierarchy 或是 SidRetrievalStrategy 存在呢？是因为调用 Acl 进行权限检查之前，已经把相关的 Sid 得到了，再给 Acl 的。
d) Ace, Permission: Ace 存储 Sid, Permission，提供给 Acl 鉴权用。增加时间条件的话，最基本的，就是要在 Ace 中，增加时间条件字段。Permission 是用二进制存储的，但默认实现的数据库存储并不是，是一个一条，存在数据库里面的。

好吧，概念还是非常多的，不过鉴于权限控制本身就是个复杂的话题，ss 这些设计的我觉得已经非常好，也基本够用了。