[commons-io]FileUtils.copyFile()方法的两个参数都是“文件”
FileUtils.copyFile()方法的两个参数都是“文件”，而不是“目录”
[ibatis]执行resultMap里配置的子select时，是否生成了新的connection
查询对象：一棵树状Bean 环境：Spring Template + JdbcTransactionManager + ibatis 发现： 1.执行树型查询时，ibatis中ExternalTransaction类曾多次执行connection.close()方法 2.Spring Template 生成的Transaction实例并不是ExternalTransaction，而是UserProvidedTransaction。看来Spring Template在执行一次查询的时候使用两种Transaction，一类由Spring模板维护，它的生命周期为整个session，一个session里只有一个；另一类用作具体的db request，每做一次query就生成一个 3. Spring Template 使用的 SqlMapExecutor是SqlMapSession，这个类还继承了SqlMapTransactionManager接口，使得每次执行查询后都会调用ExternalTransaction来关闭一下Connection (SqlMapExecutorDelegate的autoEndTransaction()方法) 4. 不管有没有Spring Template，ibatis同一个session内的每个request都要用一个新的Connection！ 也就是树型Bean千万不能用ibatis来做查询的框架！
Spring + Hibernate：hibernate配置文件不在classes下，怎么办？
配置hibernate.cfg.xml时，如果这个文件的路径在classes目录之上的某个目录，如web/WEB-INF/hibernate.cfg.xml，咋办？ 我开始试着将sessionFactory的configuration值配成 ../hibernate.cfg.xml，不行； 配成 file:///../hibernate.cfg.xml，也不行；看了下源代码，这个东西根本不支持用".."表示的相对路径。 configuration的类型是org.springframework.core.io.Resource，于是我们只好这样解决：写一个类实现Resource接口，在这个类中定义hibernate文件路径为web/WEB-INF/hiberate.cfg.xml，然后将类装配成Bean，并注入到sessionFactory里。 spring正常情况下用的Resource类是org.springframework.core.io.FileSystemResource类，因此我们的实现类应将FileSystemResource类当作我们的 实现类的 一个成员变量，将这个成员变量的path设为 web/hibernate.cfg.xml的绝对路径（要利用java.io.File API），并通过这个成员来实现Resource接口要求实现的方法。 通过这种办法，最后测试通过。
AppFuse 1.9.3：把一个在线的用户禁用之后，他还能继续操作吗？
答案是： 不能。当然前提是：已将 filterInvocationInterceptor bean 的 alwaysReauthenticate 设为true。
[proxool] 配置时要把user和password都要写到driverUrl来
jdbc:jtds:sqlserver://ip:port;DatabaseName=db 可能不行 jdbc:jtds:sqlserver://ip:port;DatabaseName=db; user=xxx;password=yyy 这样才行 又是一个BUG!
[apache-commons] FilenameUtils.getExtension(“f”)
不是null，而是长度为0的字符串
log4j file appender 的根路径 若没有指定，那就是 ${user.dir}
有这样一个配置： log4j.appender.fileAppender.File=theLog.log 问题：那么这个 theLog.log的绝对路径是什么呢？ 答曰：${user.dir}/theLog.log 若当前运行的JAVA程序是tomcat应用，那它就是 ${catalina_home/bin/theLog.log
[EhCache] 如何在集群环境中使用Ehcache
很遗憾，EhCache不是session中的东西，因此不能仅仅利用应用服务器的 session replication使它在各个节点间维持一致 透明性是没有了，还是要显式地弄一下这个东西的。不过还好，EhCache提供的缓存分布机制还是比较简单的。只需要配置一下，不用写代码。 具体怎么配可以去官方网站看看。这里用最简短的话介绍一下实现的方案：每个实例配一个监听进程，用来接收其他实例发来的缓存通知信息；实例之前可以用组播协议互相通知，也可以用普通的IP协议进行多播。 以下是官方的正式文档： 设计思路： http://ehcache.sourceforge.net/documentation/distributed_design.html 配置办法： http://ehcache.sourceforge.net/documentation/distributed_caching.html
AppFuse1.9.3：去掉某个在线用户的权限后，该用户的权限是不是真的马上消失了？
答案是： 不会。去掉用户的权限后，该用户仍然可以执行相关的操作，即使系统管理员 “刷新了缓存” 被去掉权限的用户只有在更新自己的信息、或者退出重新登录以后，才能发现自己失去了指定的权限。 ================================================== 分析： 收集到的事实： 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 …