Chen Jian

答案是：    不会。去掉用户的权限后，该用户仍然可以执行相关的操作，即使系统管理员 “刷新了缓存”    被去掉权限的用户只有在更新自己的信息、或者退出重新登录以后，才能发现自己失去了指定的权限。 ================================================== 分析：   收集到的事实：     1.去掉用户的某权限（即角色，role）后，该用户查看自己的资料，会发现该角色的确被去掉了，但经过代码跟踪，我发现，该用户对应的Authentication对象中，本来该去掉的authrotiy还在！     2.用户在登录后，后续的操作不会被 AbstractUserDetailsAuthenticationProvider 拦截。也就是说，用户的Authentication对象不会被更新。相反，这个对象是从SerurityContext中直接取出来的老对象，见 AbstractSecurityInterceptor     authenticated = SecurityContextHolder.getContext().getAuthentication()   确认原因：     User对象在数据库中被修改后，虽然它在的内存中的对象会被更新(UserSerurityAdvice类中会显式地刷新UserCache)，但其对应的Authentication对象却不会被更新。 ============================================= 解决办法：     1. 配置 filterInvocationInterceptor 的 alwaysReauthenticate属性为true，也就是说用户每进行一次操作，都要去搜集一下它的角色。正如acegi文档所说： It (指 AbstractSecurityInterceptor) also has configurable settings to indicate whether an Authentication object should be re-authenticated on each secure object invocation. By …

AppFuse1.9.3：去掉某个在线用户的权限后，该用户的权限是不是真的马上消失了？ Read More »

1.在 filterInvocationInterceptor Bean 中配置 url 与 角色的关系 2.在 menu-config.xml 中配置 菜单与角色的关系 3.在 web层的userManager bean定义中 配置 userManager方法 与 角色的关系 4.Constants.java中有两个变量的名/值要修改，用到了这个两个变量的地方也都要按实际情况调整，它们是 ADMIN_ROLE 和 USER_ROLE

估计是缓存的问题，待研究 已经可以排除以下原因：    1.退出时session没有置为无效    2.IE缓存里存放了菜单的源码    3.Appfuse中的userCache设置    最终的成功解决办法：   将struts-menu版本升级到 2.4.3，并将cssHorizontalMenu.vm 和 cssVerticalMenu.vm替换为 appFuse2.0中的版本。    因为struts-menu的官方主页说了 ：All users are encouraged to upgrade to at least 2.4.2 as some major performance and security issues were solved in this release. Most of them only affect folks using the VelocityDisplayer.)，  

    在J2EE分布式系统中，我们需要选取某种远程服务协议，在分布的进程之间进行交互。可供选择的协议 EJB、 基于SOAP的Web Service 这些重量级的，也有像RMI、Socket这种比较原始的。但最近了解到了Caucho公司的 Hessian/Burlap方案，我觉得这种方案才是最合适的， 因为它没有上文所述其他几种方案的缺点，而且，如果把Hessian/Burlap与Spring结合使用，设计者将感到无比的方便。    下面就逐个说说这些“不好的”方案，再介绍Hessian/Burlap方案。       a. EJB。 这就不用说了，EJB极其笨重，配置会累死人，性能也糟糕。       b. 基于SOAP的Web Service。 有着和EJB类似的缺点。声明一个服务很麻烦，而且用SOAP协议传输数据会浪费大量的带宽，因为SOAP基于XML，而XML中大部分的数据并不一定是业务数据，而仅仅是元数据。       c. RMI。如果与Spring结合使用，配置不算麻烦。但是其服务接口受到制约（必须继承java.rmi.Remote接口），而且RMI服务只能使用1109端口。       d. Socket。 这应该是最让程序员放心的协议了，因为程序员想怎么搞就怎么搞。但有两个代价：           i.要做很多底层的、基础性的事情。比如说，程序员不得不手写烦人的Socket客户端和服务端代码，要直接与 Socket、InputStream、OutputStream 等底层类打交道；要手工实现安全性、并发、转码、日志等功能；Socket服务器也要通过一个独立的MAIN程序来启动，而不能放到J2EE服务器产品运营，也就是说利用不了J2EE服务器的监控功能。          ii.使用SOCKET方式交互，需要设计交互的报文规范。这是一件非常累人的工作。报文既要使用统一的方式来组报和解报、又要保证报文不会引起歧义。当远程服务的接口变更时，报文可能要做极大的变更。举个例子，在原来的报文中插入一个字段，其后面的字段位置都要后移，这样的话，组报、解报代码可能都要大改。       e. Hessian/Burlap。它的优点就是解决了以上几种方案的缺点。           i. 易用性。非常方便，服务不需要继承奇怪的接口，也没有多少配置，只需包装成一个Servet即可。与Spring的注入机制结合使用的话，客户端和服务端都会很舒服。           ii. 性能好。Burlap也是用XML传输数据，但比SOAP简约的多；而Hessian是二进制协议，更加节省带宽。           iii. 它也是 基于Http的，它可以穿透防火墙，其实它也是Web Service的一种协议，           iv.为程序员 免去了底层性、基础性的工作。因为它是一个Servlet，底层性的工作，比如 输入输出流、并发、日志等事情 都可以交给Tomcat之类的、现成的服务器; 有了应用服务器，还可以获得其他的一些功能，比如监控、集群什么的；它还可以配置用户名和密码，安全性的工作也包干了           v. 不用设计报文了。因为服务端的服务是以 …

强烈推荐使用 Hessian/Burlap 作为J2EE分布式系统内部 的 远程服务方案 Read More »

house-keeping-sleep-time: house keeper 保留线程处于睡眠状态的最长时间,house keeper 的职责就是检查各个连接的状态,并判断是否需要销毁或者创建，这个的默认值是30秒。 house-keeping-test-sql: 如果发现了空闲的数据库连接.house keeper 将会用这个语句来测试.这个语句最好非常快的被执行.如果没有定义,测试过程将会被忽略。 maximum-active-time: 如果housekeeper 检测到某个线程的活动时间大于这个数值.它将会杀掉这个线程.所以确认一下你的服务器的带宽.然后定一个合适的值.默认是5分钟。经常有些人或许会遇到正在执行的程序忽然拒绝连接，莫明其妙的程序假死，这些都与这个参数的设置有关，我们大部分数据库操作都会在5分钟之内完成，可是偏偏有些可能5分钟还完成不了，而这个值如果按照默认值的话，连接池就会不管你到底有没有执行完，都会强行关闭数据库连接，所以这个值你可要小心设置哦：） maximum-connection-count: 最大的数据库连接数.一般的大应用设置30就足够了。 maximum-connection-lifetime: 一个线程的最大寿命. minimum-connection-count: 最小的数据库连接数，一般最好事先初始化一部分连接这样，对于初次连接数据库的应用效率比较高，推荐设置5－10 prototype-count: 连接池中可用的连接数量.如果当前的连接池中的连接少于这个数值.新的连接将被建立(假设没有超过最大可用数).例如.我们有3个活动连接2个可用连接,而我们的prototype-count是4,那么数据库连接池将试图建立另外2个连接.这和 minimum-connection-count不同. minimum-connection-count把活动的连接也计算在内.prototype-count 是spare connections 的数量.

今天偶然发现，如果使用了Spring框架，如果要从datasource里拿到connection并且使它自动被事务管理器掌管，则应该： Application code is required to retrieve the JDBC connection via DataSourceUtils.getConnection(DataSource) instead of J2EE’s standard DataSource.getConnection. 如果资源是JDBC 连接，则用DataSourceUtils 如果资源是JDO 连接，则用PersistenceManagerFactoryUtils 如果资源是Hibernate session，则用 SessionFactoryUtils

如果用XML来配，是这样的： <access-constraint> <ip-filter> <enable>true</enable> <allow-access>true</allow-access> <ip-collection> <client-ip-address>192.168.1.20</client-ip-address> </ip-collection> </ip-filter> </access-constraint> 如果用代码来写，就这样： AccessConstraintConfig accessConstraintConfig = new AccessConstraintConfig(); IpFilterConfig ipFilterConfig = new IpFilterConfig(); ipFilterConfig.setEnable(true); ipFilterConfig.setAllowAccess(true); ipFilterConfig.addClientIpAddress("192.168.1.20"); accessConstraintConfig.setIpFilterConfig(ipFilterConfig); server.setAccessConstraintConfig(accessConstraintConfig); 要注意，QuickServer中，本机实际地址和127.0.0.1这个地址是区别对待的。若本机IP是192.168.1.20：     1.若本机以 telnet 192.168.1.20 方式访问服务器，则应添加的IP是 192.168.1.20       2.若本机以 telnet localhost 方式访问服务器，则应添加的IP是 127.0.0.1  

System.out.println(handler.getDataMode(DataType.IN)); System.out.println(handler.getDataMode(DataType.OUT));                 结果为：    String     String

// 转型为MultipartHttpRequest：            MultipartHttpServletRequest multipartRequest = (MultipartHttpServletRequest) request;            // 获得文件：            MultipartFile file = multipartRequest.getFile("filename");    //filename表单参数名         if(MyStringUtil.isEmptyOrNullAfterTrim(file.getOriginalFilename())){         throw new RuntimeException("上传文件不能为空");         } FileCopyUtils.copy(file.getBytes(), objectFile);

     30个线程，做同一件工作：到远程网站上下载页面。我们发现，线程运行的机器 在网站当机时 比网站正常时 使用的内存 更多！