回顾：
前几篇博客中，我们都是在acegi配置文件中配置那些web资源需要保护，这次为了更接近企业开发，我们把web资源角色信息都存放到数据库中。
那既然自己设计表，那么就需要自己重新定义 objectDefinitionSource了，那先看看我们原来acegi的配置：
那默认的调用PathBasedFilterInvocationDefinitionMap类，
主要的方法如下：
前提说明：
在最近几篇博客中，都有debug步骤，其中debug步骤，是因为调试中为了看源码必经之路，为了更让同学们了解其调用步骤，所以才加入debug步骤。在博客中不可能把所有的源代码贴出，所以只能截关键代码。因为有时自定义类，想知道何时何地以及如何调到自己实现类。
有时为了明白框架为何抛出异常以及为何转到这种页面，这个时候都需要一遍遍又一遍遍又又……的debug，哈哈，大家肯定都有这种经历吧
具体开发步骤：
开发环境：
MyEclispe10.7.1+tomcat6.0.37+acegi1.0.5+spring2.0
项目目录如下：
其中readme主要用来记录本次验证目的
讲解：
根据上述默认的PathBasedFilterInvocationDefinitionMap类，我们主要重写其方法即可，只要把其角色信息封装成ConfigAttributeDefinition对象返回即可。
封装的类信息如下：
debug运行：
当职责连运行到FilterSecurityInterceptor类的doFilter时：
第一步：进入FilterSecurityInterceptor类的DoFilter方法中
第二步：进入invoke方法
第三步：进入beforeInvocation方法，此方法主要获取其web资源对应的角色信息
第四步：通过抽象类查询url对应的角色，然后调用自定义类查询url对应的角色信息
若访问的url有相应的权限，则返回其角色；否则则返回null。若返回后，我们看看后面是如何继续执行的？
若数据库中没有其url对应的角色信息，则程序职责连继续执行，因为FilterSecurityInterceptor是最后一个Filter，因为执行完后，则正常显示其页面
总结：
通过这篇博客，为了跟接近实际情况，我们把资源角色信息存放到数据库中，为了方便而言，我们设计的表如下：
test_resource：主要用来存放URL的。其中的字段就一个URL
varchar2(100) url
test_resource_role:主要用来存放URL与对应的角色
varchar2(100) url,varchar2(50) role
PS：
程序中用到sql查询，其实就是表的所有字段了，为了方便理解，没有设计复杂的数据结构，其实无论你的表如何设计，最终只要返回其url对应的角色信息，其返回值只要按照某种格式封装即可。
思路：
为了定制自己项目需求，我们开始实现其提供的接口，但是往往这个时候我们如何实现，如何自定义，又如何返回呢?
其实，既然他对外提供了接口，他们通常有一种默认实现方式，我们只要参考其框架默认实现方式自定义即可哈。
比如我们定制logoutFilter，参考原有的logoutFilter；定制userdetailservicie，参考默认实现jdbcImpl；定制objectDefinitionSource，参考默认实现PathBasedFilterInvocationDefinitionMap类。