然而，该框架默认的权限配置方式在xml中，又因为新版本隐藏了实现细节，在动态权限的扩展上，能力变小了。在验权过程中，遇到的问题不多。但在授权时，如果是acegi，人们可以通过继承AbstractFilterInvocationDefinitionSource类实现在授权（即资源角色和用户角色的匹配）前，针对资源的角色的获取。而新版本因为用新标签进行了整合，这个过程被默认的类实现隐藏掉了，包括过滤器，资源获取和角色定义等过程都由框架来实现，于是很多人在使用Spring Security2时也想通过改动DefaultFilterInvocationDefinitionSource对资源的获取来实现数据库或文件中的动态的角色。不过这样的改动侵入性比较高，而且还保留了acegi的痕迹，也违背了开闭的原则。

其实，我们完全可以通过Spring Security2 accessManager提供的自定义投票机制来解决这个问题，这样既不影响现有的基于URL的配置，还可以加入自己的动态的权限配置。

         其实现策略如下：

1 定义类DynamicRoleVoter实现AccessDecisionVoter，注入实现接口DynamicRoleProvider（用来定义获取角色的方法）的提供动态角色的类

2 在两个supports方法中返回true

3 在vote方法中，有三个参数(Authentication authentication, Object object,

ConfigAttributeDefinition config) 通过第一个获取用户的权限集合，第二个可以获取到资源对象，进而通过DynamicRoleProvider获取到角色集合进行匹配。

4 在配置文件中加入DynamicRoleVoter，如下：

<beans:bean id="accessDecisionManager" class="org.springframework.security.vote.AffirmativeBased">
<beans:property name="decisionVoters">
<beans:list>
<beans:bean class="org.springframework.security.vote.RoleVoter" />
<beans:bean class="org.springframework.security.vote.AuthenticatedVoter" />
<beans:bean class="DynamicRoleVoter">
    <beans:property name="dynamicRoleProvider">
        <beans:ref local="dynamicRoleProvider"/>
</beans:property>
</beans:bean>
</beans:list>
</beans:property>
</beans:bean>
<beans:bean id=” dynamicRoleProvider” class=”…”>
    ……
</beans:bean>

下面一一展开讨论

（一）保障安全性

安全性的主要解决方案是利用Java提供的keytool生成一个keystore，并利用这个keystore对jar包进行signjar的操作。
整个对Java文件的编译，打包和signjar过程可以利用Ant来完成，比如下面的Ant脚本片段就是用来处理signjar的，大家也可以通过相应的Java命令直接处理：

< target  name ="signjar"  depends ="jar" >
  < signjar  jar ="example.jar"
  keystore ="${basedir}/yangyi.keystore"  storepass ="mypassword"  alias ="mykey" ></ signjar >
</ target >

如果直接用命令，则其形式为：
jarsigner [ options ] jar-file alias
具体的操作方法可以参考下面的链接：
http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/jarsigner.html
通过这个signjar的操作，我们就给这个包中的类进行了一次数字签名，这样，当Applet进行默认许可之外的操作时，窗口将弹出这个数字签名要求本地用户进行确认，只有在确认后，用户才可以继续进行操作。

这样我们可以在第一次用户运行Applet程序时，在用户的许可下动态地在用户的$user.home/.java.policy下生成一个授权文件，以后就可以执行需要的操作了，为保证客户端的安全性，仅赋予用户执行特定文件夹权限的权利，如（仅作为例子,可以根据需要自己配置文件和Socket访问权限）：
grant codeBase "file:/home/yiyang/test/×" {
 java.security.AllPermission;
};

（二）下载并管理库支持

这个过程可以通过Java的URL类提供的openConnection方法来获取一个InputStream从而获取到远程的资源（包括支持库和配置文件两部分）
1）对于配置文件，因为其内容都比较少，而且比较简单，可以直接通过输入流来获取，这是没有异议的；
2）对于库文件，在下载之前先到我们管理的库的目录下找到版本索引文件（我们设定一个版本索引文件来管理升级），这个版本索引文件如下所示：

time={资源获取的时间戳}
lib1.jar=1.0
lib2.jar=1.1

其中，服务器端也保留有一份这样的版本文件，当下载库文件时，首先对客户端和服务端的库的总时间戳进行比较，如果客户端大于或等于服务端，则不需下载，否则，如果客户端对应项目为空或者其总的时间戳小于服务端，则进一步比较内部库文件的版本，发现版本低的库或在客户端不存在的库后，自动到服务器上进行下载，在下载成功后，更新客户端的索引文件。

（三）通信

这个问题小弟曾在以往的blog中有过详细的讨论，可以到http://yangyi.blogjava.net中的相应随笔中找到答案。总的来说，在类型协议并不复杂，且客户端，服务端均为Java开发的情况下，应用Hessian是一个好的解决方案，需要指出的是Hessian中的代码对客户端来说并不是全部必须的，大家可以根据客户端的使用情况对这个库进行瘦身。只保留作为客户端必要的类即可。

（四）动态的实例化及插件结构

我们要实现用户界面的集成，从根本上说要解决下面的几个问题：
1）菜单集成
2）支持库集成
3）集成点
4）输出变量
对于客户端为Applet开发的插件，我们把上面的四项配置统一在XML文件中进行描述定义。
这里需要注意的是菜单要提供名称，支持库要提供下载路径或者本地路径，集成点我们希望是一个JPanel。
在定义好XML后，可以到网址：http://www.flame-ware.com/xml2xsd/去获得一个对应的schema，利用这个schema和JAXB提供的xjc工具，我们就可以生成对应的XML操作类，来对配置进行处理。
对于菜单的集成可以动态地在JMenu中添加MenuItem（表示插件的功能）
根据配置的支持库的位置，我们可以通过Java的URLClassLoader对库进行动态的加载，然后根据相应的集成点，获取实例，这个过程的示例代码如下所示：

File f  =   new  File( " a.jar " );  // a.jar是我们从配置文件中读取的支持库
URL url  =   null ;
Class lib  =   null ;
try   {
 url  =  f.toURI().toURL();
 lib  =  Class.forName( " Lib " ,  true ,  new  URLClassLoader(
    new  URL[]  { url } ));  // Lib是我们从配置文件中读取的集成点
 JPanel plugin_panel  =  (JPanel)lib.newInstance();
  return  plugin_panel;
}   catch  (Exception e)  {
 e.printStackTrace();
}

对于输出变量，其主要作用是用户各个插件之间的信息交互，我们可以通过一个总的HashMap来实现，为避免变量值出现冲突，在变量名前自动加上插件名的前缀。
如plug_in1的变量var1，其系统名称为：plug_in1__var1.

解决了上面的四个障碍，我们就可以把精力投入到具体的功能实现上了。