锁（locking）
业务逻辑的实现过程中，往往需要保证数据访问的排他性。如在金融系统的日终结算 处理中，我们希望针对某个cut-off时间点的数据进行处理，而不希望在结算进行过程中 （可能是几秒种，也可能是几个小时），数据再发生变化。此时，我们就需要通过一些机制来保证这些数据在某个操作过程中不会被外界修改，这样的机制，在这里，也就是所谓 的“锁”，即给我们选定的目标数据上锁，使其无法被其他程序修改。 Hibernate支持两种锁机制：即通常所说的“悲观锁（Pessimistic Locking）” 和“乐观锁（Optimistic Locking）”。

一 ：悲观锁（Pessimistic Locking）
悲观锁，正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定 状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能 真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系 统不会修改数据）。 一个典型的倚赖数据库的悲观锁调用： select * from account where name=”Erica” for update 这条sql 语句锁定了account 表中所有符合检索条件（name=”Erica”）的记录。 本次事务提交之前（事务提交时会释放事务过程中的锁），外界无法修改这些记录。 Hibernate的悲观锁，也是基于数据库的锁机制实现。 下面的代码实现了对查询记录的加锁：

1 String hqlStr  =   " from TUser as user where user.name=’Erica’ " ; 
2 Query query  =  session.createQuery(hqlStr); 
3 query.setLockMode( " user " ,LockMode.UPGRADE);  // 加锁 
4 List userList  =  query.list(); // 执行查询，

获取数据 query.setLockMode 对查询语句中特定别名所对应的记录进行加锁（我们为 TUser类指定了一个别名“user”），这里也就是对返回的所有user记录进行加锁。 观察运行期Hibernate生成的SQL语句： 

1 select tuser0_.id as id, tuser0_.name as name, tuser0_.group_id as group_id, tuser0_.user_type as user_type, tuser0_.sex as sex from t_user tuser0_ where (tuser0_.name = ’Erica’ )  for  update

 这里Hibernate通过使用数据库的for update子句实现了悲观锁机制。 Hibernate的加锁模式有：
? LockMode.NONE ： 无锁机制。
? LockMode.WRITE ：Hibernate在Insert和Update记录的时候会自动 获取。
? LockMode.READ ： Hibernate在读取记录的时候会自动获取。

以上这三种锁机制一般由Hibernate内部使用，如Hibernate为了保证Update 过程中对象不会被外界修改，会在save方法实现中自动为目标对象加上WRITE锁。
 
? LockMode.UPGRADE ：利用数据库的for update子句加锁。
? LockMode. UPGRADE_NOWAIT ：Oracle的特定实现，利用Oracle的for update nowait子句实现加锁。

上面这两种锁机制是我们在应用层较为常用的，加锁一般通过以下方法实现：
Criteria.setLockMode
Query.setLockMode
Session.lock
注意，只有在查询开始之前（也就是Hiberate 生成SQL 之前）设定加锁，才会 真正通过数据库的锁机制进行加锁处理，否则，数据已经通过不包含for update 子句的Select SQL加载进来，所谓数据库加锁也就无从谈起。

二 ：乐观锁（Optimistic Locking）
相对悲观锁而言，乐观锁机制采取了更加宽松的加锁机制。悲观锁大多数情况下依 靠数据库的锁机制实现，以保证操作最大程度的独占性。但随之而来的就是数据库 性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。 如一个金融系统，当某个操作员读取用户的数据，并在读出的用户数据的基础上进 行修改时（如更改用户帐户余额），如果采用悲观锁机制，也就意味着整个操作过 程中（从操作员读出数据、开始修改直至提交修改结果的全过程，甚至还包括操作 员中途去煮咖啡的时间），数据库记录始终处于加锁状态，可以想见，如果面对几 百上千个并发，这样的情况将导致怎样的后果。 乐观锁机制在一定程度上解决了这个问题。乐观锁 大多是基于数据版本 （Version）记录机制实现。何谓数据版本？即为数据增加一个版本标识，在基于 数据库表的版本解决方案中，一般是通过为数据库表增加一个“version”字段来 实现。 读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提 交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据 版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。 对于上面修改用户帐户信息的例子而言，假设 ：

数据库中帐户信息表中有一个 version字段，当前值为1；而当前帐户余额字段（balance）为$100。
1 ：操作员A 此时将其读出（version=1），并从其帐户余额中扣除$50 （$100-$50）。
2 ： 在操作员A操作的过程中，操作员B也读入此用户信息（version=1），并 从其帐户余额中扣除$20（$100-$20）。
3： 操作员A完成了修改工作，将数据版本号加一（version=2），连同帐户扣 除后余额（balance=$50），提交至数据库更新，此时由于提交数据版本大 于数据库记录当前版本，数据被更新，数据库记录version更新为2。
4： 操作员B完成了操作，也将版本号加一（version=2）试图向数据库提交数 据（balance=$80），但此时比对数据库记录版本时发现，操作员B提交的 数据版本号为2，数据库记录当前版本也为2，不满足“提交版本必须大于记 录当前版本才能执行更新“的乐观锁策略，因此，操作员B 的提交被驳回。 这样，就避免了操作员B 用基于version=1 的旧数据修改的结果覆盖操作 员A的操作结果的可能。

从上面的例子可以看出，乐观锁机制避免了长事务中的数据库加锁开销（操作员A 和操作员B操作过程中，都没有对数据库数据加锁），大大提升了大并发量下的系 统整体性能表现。 需要注意的是，乐观锁机制往往基于系统中的数据存储逻辑，因此也具备一定的局 限性，如在上例中，由于乐观锁机制是在我们的系统中实现，来自外部系统的用户 余额更新操作不受我们系统的控制，因此可能会造成脏数据被更新到数据库中。在 系统设计阶段，我们应该充分考虑到这些情况出现的可能性，并进行相应调整（如 将乐观锁策略在数据库存储过程中实现，对外只开放基于此存储过程的数据更新途 径，而不是将数据库表直接对外公开）。 Hibernate 在其数据访问引擎中内置了乐观锁实现。如果不用考虑外部系统对数 据库的更新操作，利用Hibernate提供的透明化乐观锁实现，将大大提升我们的 生产力。 Hibernate中可以通过class描述符的optimistic-lock属性结合version 描述符指定。
现在，我们为之前示例中的TUser加上乐观锁机制。
 
1． 首先为TUser的class描述符添加optimistic-lock属性：

< hibernate - mapping >  
< class  
name = " org.hibernate.sample.TUser "  
table = " t_user "  
dynamic - update = " true "  
dynamic - insert = " true "  
optimistic - lock = " version "  
>  
…… 
</ class >  
</ hibernate - mapping >  

optimistic-lock属性有如下可选取值：
? none 无乐观锁
? version 通过版本机制实现乐观锁
? dirty 通过检查发生变动过的属性实现乐观锁
? all 通过检查所有属性实现乐观锁

其中通过version实现的乐观锁机制是Hibernate官方推荐的乐观锁实现，同时也 是Hibernate中，目前唯一在数据对象脱离Session发生修改的情况下依然有效的锁机 制。因此，一般情况下，我们都选择version方式作为Hibernate乐观锁实现机制。

2． 添加一个Version属性描述符
代码内容

 1 < hibernate - mapping >   
 2 < class   
 3 name = " org.hibernate.sample.TUser "   
 4 table = " t_user "   
 5 dynamic - update = " true "   
 6 dynamic - insert = " true "   
 7 optimistic - lock = " version "   
 8 >   
 9 < id  
10 name = " id "   
11 column = " id "   
12 type = " java.lang.Integer "   
13 >   
14 < generator  class = " native " >   
15 </ generator >   
16 </ id >   
17 < version  
18 column = " version "   
19 name = " version "   
20 type = " java.lang.Integer "   
21 />   
22 ……  
23 </ class >   
24 </ hibernate - mapping >   
25

注意version 节点必须出现在ID 节点之后。 这里我们声明了一个version属性，用于存放用户的版本信息，保存在TUser表的 version字段中。 此时如果我们尝试编写一段代码，更新TUser表中记录数据，如：
代码内容

1 Criteria criteria  =  session.createCriteria(TUser. class );  
2 criteria.add(Expression.eq( " name " , " Erica " ));  
3 List userList  =  criteria.list();  
4 TUser user  = (TUser)userList.get( 0 );  
5 Transaction tx  =  session.beginTransaction();  
6 user.setUserType( 1 );  // 更新UserType字段  
7 tx.commit();  
8

每次对TUser进行更新的时候，我们可以发现，数据库中的version都在递增。 而如果我们尝试在tx.commit 之前，启动另外一个Session，对名为Erica 的用 户进行操作，以模拟并发更新时的情形：
代码内容

 1 Session session =  getSession();  
 2 Criteria criteria  =  session.createCriteria(TUser. class );  
 3 criteria.add(Expression.eq( " name " , " Erica " ));  
 4 Session session2  =  getSession();  
 5 Criteria criteria2  =  session2.createCriteria(TUser. class );  
 6 criteria2.add(Expression.eq( " name " , " Erica " ));  
 7 List userList  =  criteria.list();  
 8 List userList2  =  criteria2.list();TUser user  = (TUser)userList.get( 0 );  
 9 TUser user2  = (TUser)userList2.get( 0 );  
10 Transaction tx  =  session.beginTransaction();  
11 Transaction tx2  =  session2.beginTransaction();  
12 user2.setUserType( 99 );  
13 tx2.commit();  
14 user.setUserType( 1 );  
15 tx.commit();  
16

执行以上代码，代码将在tx.commit()处抛出StaleObjectStateException异 常，并指出版本检查失败，当前事务正在试图提交一个过期数据。通过捕捉这个异常，我 们就可以在乐观锁校验失败时进行相应处理。

说明一下,这一篇文章的用到的lucene,是用2.0版本的,主要在查询的时候2.0版本的lucene与以前的版本有了一些区别.
其实这一些代码都是早几个月写的,自己很懒,所以到今天才写到自己的博客上,高深的文章自己写不了，只能记录下一些简单的记录与点滴，其中的代码算是自娱自乐的，希望高手不要把重构之类的砸下来...

1、在windows系统下的的C盘，建一个名叫s的文件夹,在该文件夹里面随便建三个txt文件，随便起名啦，就叫"1.txt","2.txt"和"3.txt"啦
其中1.txt的内容如下：

2、下载lucene包，放在classpath路径中
建立索引:

索引的结果：

3、建立了索引之后，查询啦....

其运行结果：

这是lucene1.4.3版的API

Lucene 其实很简单的,它最主要就是做两件事:建立索引和进行搜索
来看一些在lucene中使用的术语,这里并不打算作详细的介绍,只是点一下而已----因为这一个世界有一种好东西，叫搜索。

IndexWriter:lucene中最重要的的类之一，它主要是用来将文档加入索引，同时控制索引过程中的一些参数使用。

Analyzer:分析器,主要用于分析搜索引擎遇到的各种文本。常用的有StandardAnalyzer分析器,StopAnalyzer分析器,WhitespaceAnalyzer分析器等。

Directory:索引存放的位置;lucene提供了两种索引存放的位置，一种是磁盘，一种是内存。一般情况将索引放在磁盘上；相应地lucene提供了FSDirectory和RAMDirectory两个类。

Document:文档;Document相当于一个要进行索引的单元，任何可以想要被索引的文件都必须转化为Document对象才能进行索引。

Field：字段。

IndexSearcher:是lucene中最基本的检索工具，所有的检索都会用到IndexSearcher工具;

Query:查询，lucene中支持模糊查询，语义查询，短语查询，组合查询等等,如有TermQuery,BooleanQuery,RangeQuery,WildcardQuery等一些类。

QueryParser: 是一个解析用户输入的工具，可以通过扫描用户输入的字符串，生成Query对象。

Hits:在搜索完成之后，需要把搜索结果返回并显示给用户，只有这样才算是完成搜索的目的。在lucene中，搜索的结果的集合是用Hits类的实例来表示的。

上面作了一大堆名词解释，下面就看几个简单的实例吧:
1、简单的的StandardAnalyzer测试例子

2、看另一个实例,简单地建立索引，进行搜索

很久没有看lucene了，这两三天又复习了一下,上一些代码都是前几个月写的，只是改动了一些字符串和包名显示。转载时请说明，文章来自:http://lighter.javaeye.com。
如有什么错误的地方，恳请指出，谢谢。

StandardAnalyzer是lucene中内置的"标准分析器",可以做如下功能:
1、对原有句子按照空格进行了分词
2、所有的大写字母都可以能转换为小写的字母
3、可以去掉一些没有用处的单词，例如"is","the","are"等单词，也删除了所有的标点
同时也可以对中文进行分词(效果不好),现在有很多的中文分词包可以采用

昨天，由于程序中需要用到一个WEB TABS样式的页面，GOOGLE之，才发现这东西真不好找。
displaytag 这个东西计划要支持TABS，为啥只是计划，虽然它的表格样式看起来不错。
webtabs 这个嘛，样子太丑了，拿不出手。
prizetags 这个可控制的属性太少了，不爽。
Ditchnet JSP Tabs Taglib 就是它，为什么没有地方能下载到，哪位好心人能告诉我？

下面的这个站收录的比较全，收藏之。
东西还真不少，慢慢学啦，可惜没有我想要的
【Java开源 Jsp标签库】
Posted by E_wsq 2006-3-29 9:32:00
displytag

与Struts结合使用最出名的一个tag主要是显示表格数据很漂亮、完善。
500)this.style.width=500;” border=0> http://displaytag.sourceforge.net/
cewolf tag

用来在web上显示复杂图形报表的一个jsp tag。
500)this.style.width=500;” border=0> http://cewolf.sourceforge.net/
Loading Tab

当一个复杂的操作可以加载比较长的时间时，用这个tag。
500)this.style.width=500;” border=0> http://www.mycgiserver.com/~eboudrant/#taglibs
DbForms

DbForms!它是一个基于 Java (Servlet,JSP/Taglib)的快速应用程序开发环境，可以帮助开发人员快速建造基于Web的数据库应用程序。
500)this.style.width=500;” border=0> http://jdbforms.sourceforge.net/
Jakarta Taglibs

Jakarta Taglibs 是为JSP定制标签库和相关的项目提供的一个开源仓库，如 TagLibraryValidator类，和对页面生成工具的扩展来支持标签库。Jakarta Taglibs 也包括了对JSP Standard Tag Library (JSTL)的参考实现。这个实现基于项目标准。目前，在Jakarta Taglibs 中没有其它标签库代表了Java Community Process (JCP) 标准。
500)this.style.width=500;” border=0> http://jakarta.apache.org/taglibs/index.html
EasyLDAP

关键字 J2EE Spring Acegi

[简介]

对于一个典型的Web应用，完善的认证和授权机制是必不可少的，在SpringFramework中，Juergen Hoeller提供的范例JPetStore给了一些这方面的介绍，但还远远不够，Acegi是一个专门为SpringFramework提供安全机制的 项目，全称为Acegi Security System for Spring，当前版本为0.5.1，就其目前提供的功能，应该可以满足绝大多数应用的需求。

本文的主要目的是希望能够说明如何在基于Spring构架的Web应用中使用Acegi，而不是详细介绍其中的每个接口、每个类。注意，即使对已经存在的Spring应用，通过下面介绍的步骤，也可以马上享受到Acegi提供的认证和授权。

[基础工作]
在你的Web应用的lib中添加Acegi下载包中的acegi-security.jar

[web.xml]
实现认证和授权的最常用的方法是通过filter，Acegi亦是如此，通常Acegi需要在web.xml添加以下5个filter:

<filter>
<filter-name>Acegi Channel Processing Filter</filter-name>
<filter-class>net.sf.acegisecurity.util.FilterToBeanProxy</filter-class>
<init-param>
<param-name>targetClass</param-name>
<param-value>net.sf.acegisecurity.securechannel.ChannelProcessingFilter</param-value>
</init-param>
</filter>
<filter>
<filter-name>Acegi Authentication Processing Filter</filter-name>
<filter-class>net.sf.acegisecurity.util.FilterToBeanProxy</filter-class>
<init-param>
<param-name>targetClass</param-name>
<param-value>net.sf.acegisecurity.ui.webapp.AuthenticationProcessingFilter</param-value>
</init-param>
</filter>
<filter>
<filter-name>Acegi HTTP BASIC Authorization Filter</filter-name>
<filter-class>net.sf.acegisecurity.util.FilterToBeanProxy</filter-class>
<init-param>
<param-name>targetClass</param-name>
<param-value>net.sf.acegisecurity.ui.basicauth.BasicProcessingFilter</param-value>
</init-param>
</filter>
<filter>
<filter-name>Acegi Security System for Spring Auto Integration Filter</filter-name>
<filter-class>net.sf.acegisecurity.ui.AutoIntegrationFilter</filter-class>
</filter>
<filter>
<filter-name>Acegi HTTP Request Security Filter</filter-name>
<filter-class>net.sf.acegisecurity.util.FilterToBeanProxy</filter-class>
<init-param>
<param-name>targetClass</param-name>
<param-value>net.sf.acegisecurity.intercept.web.SecurityEnforcementFilter</param-value>
</init-param>
</filter>

最先引起迷惑的是net.sf.acegisecurity.util.FilterToBeanProxy，Acegi自己的文档上解释是： “What FilterToBeanProxy does is delegate the Filter’s methods through to a bean which is obtained from the
Spring application context. This enables the bean to benefit from the Spring application context lifecycle support and configuration flexibility.”，如希望深究的话，去看看源代码应该不难理解。

再下来就是添加filter-mapping了：
<filter-mapping>
<filter-name>Acegi Channel Processing Filter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>Acegi Authentication Processing Filter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>Acegi HTTP BASIC Authorization Filter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>Acegi Security System for Spring Auto Integration Filter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>Acegi HTTP Request Security Filter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>

这里，需要注意以下两点：
1) 这几个filter的顺序是不能更改的，顺序不对将无法正常工作；
2) 如果你的应用不需要安全传输，如https，则将”Acegi Channel Processing Filter”相关内容注释掉即可；
3) 如果你的应用不需要Spring提供的远程访问机制，如Hessian and Burlap，将”Acegi HTTP BASIC Authorization
Filter”相关内容注释掉即可。

[applicationContext.xml]
接下来就是要添加applicationContext.xml中的内容了，从刚才FilterToBeanFactory的解释可以看出，真正的filter都
在Spring的applicationContext中管理：

1) 首先，你的数据库中必须具有保存用户名和密码的table，Acegi要求table的schema必须如下：

CREATE TABLE users (
username VARCHAR(50) NOT NULL PRIMARY KEY,
password VARCHAR(50) NOT NULL,
enabled BIT NOT NULL
);
CREATE TABLE authorities (
username VARCHAR(50) NOT NULL,
authority VARCHAR(50) NOT NULL
);
CREATE UNIQUE INDEX ix_auth_username ON authorities ( username, authority );
ALTER TABLE authorities ADD CONSTRAINT fk_authorities_users foreign key (username) REFERENCES users
(username);

2) 添加访问你的数据库的datasource和Acegi的jdbcDao，如下：

<bean id=”dataSource” class=”org.springframework.jdbc.datasource.DriverManagerDataSource”>
<property name=”driverClassName”><value>${jdbc.driverClassName}</value></property>
<property name=”url”><value>${jdbc.url}</value></property>
<property name=”username”><value>${jdbc.username}</value></property>
<property name=”password”><value>${jdbc.password}</value></property>
</bean>
<bean id=”jdbcDaoImpl” class=”net.sf.acegisecurity.providers.dao.jdbc.JdbcDaoImpl”>
<property name=”dataSource”><ref bean=”dataSource”/></property>
</bean>

3) 添加DaoAuthenticationProvider:

<bean id=”daoAuthenticationProvider” class=”net.sf.acegisecurity.providers.dao.DaoAuthenticationProvider”>
<property name=”authenticationDao”><ref bean=”authenticationDao”/></property>
<property name=”userCache”><ref bean=”userCache”/></property>
</bean>

<bean id=”userCache” class=”net.sf.acegisecurity.providers.dao.cache.EhCacheBasedUserCache”>
<property name=”minutesToIdle”><value>5</value></property>
</bean>

如果你需要对密码加密，则在daoAuthenticationProvider中加入：<property name=”passwordEncoder”><ref
bean=”passwordEncoder”/></property>，Acegi提供了几种加密方法，详细情况可看包
net.sf.acegisecurity.providers.encoding

4) 添加authenticationManager:

<bean id=”authenticationManager” class=”net.sf.acegisecurity.providers.ProviderManager”>
<property name=”providers”>
<list>
<ref bean=”daoAuthenticationProvider”/>
</list>
</property>
</bean>

5) 添加accessDecisionManager:

<bean id=”accessDecisionManager” class=”net.sf.acegisecurity.vote.AffirmativeBased”>
<property name=”allowIfAllAbstainDecisions”>
<value>false</value>
</property>
<property name=”decisionVoters”>
<list><ref bean=”roleVoter”/></list>
</property>
</bean>
<bean id=”roleVoter” class=”net.sf.acegisecurity.vote.RoleVoter”/>

6) 添加authenticationProcessingFilterEntryPoint:

<bean id=”authenticationProcessingFilterEntryPoint”
class=”net.sf.acegisecurity.ui.webapp.AuthenticationProcessingFilterEntryPoint”>
<property name=”loginFormUrl”><value>/acegilogin.jsp</value></property>
<property name=”forceHttps”><value>false</value></property>
</bean>

其中acegilogin.jsp是登陆页面，一个最简单的登录页面如下：

<%@ taglib prefix=’c’ uri=’http://java.sun.com/jstl/core’ %>
<%@ page import=”net.sf.acegisecurity.ui.AbstractProcessingFilter” %>
<%@ page import=”net.sf.acegisecurity.AuthenticationException” %>
<html>
<head>
<title>Login</title>
</head>

<body>
<h1>Login</h1>
<form action=”<c:url value=’j_acegi_security_check’/>” method=”POST”>
<table>
<tr><td>User:</td><td><input type=’text’ name=’j_username’></td></tr>
<tr><td>Password:</td><td><input type=’password’ name=’j_password’></td></tr>
<tr><td colspan=’2′><input name=”submit” type=”submit”></td></tr>
<tr><td colspan=’2′><input name=”reset” type=”reset”></td></tr>
</table>
</form>
</body>
</html>

7) 添加filterInvocationInterceptor:

<bean id=”filterInvocationInterceptor”
class=”net.sf.acegisecurity.intercept.web.FilterSecurityInterceptor”>
<property name=”authenticationManager”>
<ref bean=”authenticationManager”/>
</property>
<property name=”accessDecisionManager”>
<ref bean=”accessDecisionManager”/>
</property>
<property name=”objectDefinitionSource”>
<value>
CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
\A/sec/administrator.*\Z=ROLE_SUPERVISOR
\A/sec/user.*\Z=ROLE_TELLER
</value>
</property>
</bean>

这里请注意，要objectDefinitionSource中定义哪些页面需要权限访问，需要根据自己的应用需求进行修改，我上面给出
的定义的意思是这样的：
a. CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON意思是在比较请求路径时全部转换为小写
b. \A/sec/administrator.*\Z=ROLE_SUPERVISOR意思是只有权限为ROLE_SUPERVISOR才能访问/sec/administrator*的页面
c. \A/sec/user.*\Z=ROLE_TELLER意思是只有权限为ROLE_TELLER的用户才能访问/sec/user*的页面

8) 添加securityEnforcementFilter:

<bean id=”securityEnforcementFilter” class=”net.sf.acegisecurity.intercept.web.SecurityEnforcementFilter”>
<property name=”filterSecurityInterceptor”>
<ref bean=”filterInvocationInterceptor”/>
</property>
<property name=”authenticationEntryPoint”>
<ref bean=”authenticationProcessingFilterEntryPoint”/>
</property>
</bean>

9) 添加authenticationProcessingFilter:

<bean id=”authenticationProcessingFilter”
class=”net.sf.acegisecurity.ui.webapp.AuthenticationProcessingFilter”>
<property name=”authenticationManager”>
<ref bean=”authenticationManager”/>
</property>
<property name=”authenticationFailureUrl”>
<value>/loginerror.jsp</value>
</property>
<property name=”defaultTargetUrl”>
<value>/</value>
</property>
<property name=”filterProcessesUrl”>
<value>/j_acegi_security_check</value>
</property>
</bean>
其中authenticationFailureUrl是认证失败的页面。

10) 如果需要一些页面通过安全通道的话，添加下面的配置:

<bean id=”channelProcessingFilter” class=”net.sf.acegisecurity.securechannel.ChannelProcessingFilter”>
<property name=”channelDecisionManager”>
<ref bean=”channelDecisionManager”/>
</property>
<property name=”filterInvocationDefinitionSource”>
<value>
CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
\A/sec/administrator.*\Z=REQUIRES_SECURE_CHANNEL
\A/acegilogin.jsp.*\Z=REQUIRES_SECURE_CHANNEL
\A/j_acegi_security_check.*\Z=REQUIRES_SECURE_CHANNEL
\A.*\Z=REQUIRES_INSECURE_CHANNEL
</value>
</property>
</bean>

<bean id=”channelDecisionManager” class=”net.sf.acegisecurity.securechannel.ChannelDecisionManagerImpl”>
<property name=”channelProcessors”>
<list>
<ref bean=”secureChannelProcessor”/>
<ref bean=”insecureChannelProcessor”/>
</list>
</property>
</bean>
<bean id=”secureChannelProcessor” class=”net.sf.acegisecurity.securechannel.SecureChannelProcessor”/>
<bean id=”insecureChannelProcessor” class=”net.sf.acegisecurity.securechannel.InsecureChannelProcessor”/>

[缺少了什么？]
Acegi目前提供了两种”secure object”，分别对页面和方法进行安全认证管理，我这里介绍的只是利用
FilterSecurityInterceptor对访问页面的权限控制，除此之外，Acegi还提供了另外一个Interceptor–
MethodSecurityInterceptor，它结合runAsManager可实现对对象中的方法的权限控制，使用方法可参看Acegi自带的文档
和contact范例。

[最后要说的]
本来以为只是说明如何使用Acegi而已，应该非常简单，但真正写起来才发现想要条理清楚的理顺所有需要的bean还是很
困难的，但愿我没有遗漏太多东西，如果我的文章有什么遗漏或错误的话，还请参看Acegi自带的quick-start范例，但请
注意，这个范例是不能直接拿来用的。

原文在这里：

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=54881

<property name="dialect">org.hibernate.dialect.Oracle9Dialect</property>
<property name="show_sql">true</property>
<property name="current_session_context_class">thread</property>
<!--Fetch Size 是设定JDBC的Statement读取数据的时候每次从数据库中取出的记录条数-->
<property name="jdbc.fetch_size">20</property>
<!--Batch Size是设定对数据库进行批量删除，批量更新和批量插入的时候的批次大小，有点相当于设置Buffer缓冲区大小的意思-->
<property name="jdbc.batch_size ">20</property>
<property name="connection.username">HNMC</property>
<property name="connection.password">sundy</property>
<property name="connection.url">jdbc:oracle:thin:@192.168.0.20:1521:ora9</property>
<property name="connection.driver_class">oracle.jdbc.driver.OracleDriver</property>

<!--  在这种情况下，没问题啊 -->
<property name="c3p0.timeout">60</property>
<property name="c3p0.idle_test_period">600</property>


<!--    

<!--<property name="c3p0.idle_test_period">120</property>-->
如改以下俩值，或他们差距很大：

<property name="c3p0.timeout">600</property>

<!--<property name="c3p0.idle_test_period">60</property>-->

当我启动tomcat，运行程序后，空闲600后出现下列异常,但程序还照常运行

-->

<!-- 

Hibernate里可以设置的属性不多：
#c3p0-native property name hibernate configuration key
#c3p0.acquireIncrement hibernate.c3p0.acquire_increment
#c3p0.idleConnectionTestPeriod hibernate.c3p0.idle_test_period
#c3p0.initialPoolSize not available -- uses minimum size
#c3p0.maxIdleTime hibernate.c3p0.timeout
#c3p0.maxPoolSize hibernate.c3p0.max_size
#c3p0.maxStatements hibernate.c3p0.max_statements
#c3p0.minPoolSize hibernate.c3p0.min_size
#c3p0.testConnectionsOnCheckout hibernate.c3p0.validate hibernate 2.x only!

另外的属性你需要配置c3p0.properties
比如：
c3p0.acquireRetryDelay=111
c3p0.acquireRetryAttempts=22
c3p0.breakAfterAcquireFailure=true

-->



<property name="hibernate.connection.provider_class">org.hibernate.connection.C3P0ConnectionProvider</property>
<property name="hibernate.c3p0.max_size">2</property>
<property name="hibernate.c3p0.min_size">2</property>
<property name="hibernate.c3p0.timeout">50000</property>
<property name="hibernate.c3p0.max_statements">100</property>
<property name="hibernate.c3p0.idle_test_period">3000</property>
<property name="hibernate.c3p0.acquire_increment">2</property>

<!-- 另<property name="hibernate.c3p0.validate">false</property>确实在hibernate中不可设置  -->
<property name="hibernate.c3p0.validate">false</property>


<!--C3P0 setting-->

<property name="c3p0.max_size">20</property>
<property name="c3p0.min_size">5</property>
<!--获取连接的等待时间-->
<property name="c3p0.timeout">3600</property>
<property name="c3p0.max_statements">100</property>
<!--每隔3600毫秒测试连接是否可以正常使用-->
<property name="c3p0.idle_test_period">3600</property>
<property name="c3p0.acquire_increment">2</property>

<mapping resource="com/sundy/hnmc/beans/AccountBean.hbm.xml"/>
</session-factory>
</hibernate-configuration>



另一个设置
 <!-- 数据源配置 -->
    <bean id="dataSource" class="com.mchange.v2.c3p0.ComboPooledDataSource" destroy-method="close">
      <property name="driverClass">
        <value>org.gjt.mm.mysql.Driver</value>
      </property>
      <property name="jdbcUrl">
        <value>jdbc:mysql://localhost/tycho?useUnicode=true&amp;characterEncoding=utf-8</value>
      </property>
      <property name="properties">
        <props>
            <prop key="hibernate.hbm2ddl.auto">update</prop> 
            <prop key="c3p0.minPoolSize">1</prop> 
            <prop key="hc3p0.maxPoolSize">10</prop> 
            <prop key="hc3p0.timeout">60</prop> 
            <prop key="c3p0.max_statement">50</prop> 
            <prop key="c3p0.testConnectionOnCheckout">true</prop> 
            <prop key="hibernate.c3p0.testConnectionOnCheckout">false</prop>
            <prop key="user">root</prop> 
            <prop key="password">root</prop>
        </props>
      </property>
    </bean>



<property name="hibernate.connection.provider_class">org.hibernate.connection.C3P0ConnectionProvider</property>
<property name="hibernate.c3p0.max_size">20</property>
<property name="hibernate.c3p0.min_size">5</property>
<property name="hibernate.c3p0.timeout">120</property>
<property name="hibernate.c3p0.max_statements">100</property>
<property name="hibernate.c3p0.idle_test_period">120</property>
<property name="hibernate.c3p0.acquire_increment">2</property>

1. LoadModule proxy_module modules/mod_proxy.so   
2. LoadModule proxy_ajp_module modules/mod_proxy_ajp.so   
3. LoadModule proxy_balancer_module modules/mod_proxy_balancer.so   
4.   
5. ProxyPass /admin balancer://tomcatcluster/admin  lbmethod = byrequests   stickysession = JSESSIONID   nofailover = Off   timeout = 5   maxattempts = 3   
6. ProxyPassReverse /admin balancer://tomcatcluster/admin   
7.   
8. < Proxy  balancer://tomcatcluster >   
9. BalancerMember ajp://localhost:8009  route = web1   
10. BalancerMember ajp://localhost:10009  smax = 10   route = web2   
11. BalancerMember ajp://localhost:11009  route = web3   
12. BalancerMember ajp://localhost:12009  smax = 10   route = web4   
13. </ Proxy >   

类的初始化和对象初始化是 JVM 管理的类型生命周期中非常重要的两个环节，Google 了一遍网络，有关类装载机制的文章倒是不少，然而类初始化和对象初始化的文章并不多，特别是从字节码和 JVM 层次来分析的文章更是鲜有所见。

本文主要对类和对象初始化全过程进行分析，通过一个实际问题引入，将源代码转换成 JVM 字节码后，对 JVM 执行过程的关键点进行全面解析，并在文中穿插入了相关 JVM 规范和 JVM 的部分内部理论知识，以理论与实际结合的方式介绍对象初始化和类初始化之间的协作以及可能存在的冲突问题。

问题引入

近日我在调试一个枚举类型的解析器程序，该解析器是将数据库内一万多条枚举代码装载到缓存中，为了实现快速定位枚举代码和具体枚举类别的所有枚举元素，该类在装载枚举代码的同时对其采取两种策略建立内存索引。由于该类是一个公共服务类，在程序各个层面都会使用到它，因此我将它实现为一个单例类。这个类在我调整类实例化语句位置之前运行正常，但当我把该类实例化语句调整到静态初始化语句之前时，我的程序不再为我工作了。

下面是经过我简化后的示例代码：

package com.ccb.framework.enums;

import java.util.Collections;
import java.util.HashMap;
import java.util.Map;

public class CachingEnumResolver {
	//单态实例　一切问题皆由此行引起
	private static final CachingEnumResolver SINGLE_ENUM_RESOLVER = new
	CachingEnumResolver();
	/*MSGCODE->Category内存索引*/
	private static Map CODE_MAP_CACHE;
	static {
		CODE_MAP_CACHE = new HashMap();
		//为了说明问题,我在这里初始化一条数据
		CODE_MAP_CACHE.put("0","北京市");
	}
	
	//private, for single instance
	private CachingEnumResolver() {
		//初始化加载数据  引起问题，该方法也要负点责任
		initEnums();
	}
	
	/**
	 * 初始化所有的枚举类型
	 */
	public static void initEnums() {		
		// ~~~~~~~~~问题从这里开始暴露 ~~~~~~~~~~~//
		if (null == CODE_MAP_CACHE) {
			System.out.println("CODE_MAP_CACHE为空,问题在这里开始暴露.");
			CODE_MAP_CACHE = new HashMap();
		}
		CODE_MAP_CACHE.put("1", "北京市");
		CODE_MAP_CACHE.put("2", "云南省");
		
		//..... other code...
	}
	
	public Map getCache() {
		return Collections.unmodifiableMap(CODE_MAP_CACHE);
	}
	
	/**
	 * 获取单态实例
	 * 
	 * @return
	 */
	public static CachingEnumResolver getInstance() {
		return SINGLE_ENUM_RESOLVER;
	}
	
	public static void main(String[] args) {
		System.out.println(CachingEnumResolver.getInstance().getCache());
	}
}

想必大家看了上面的代码后会感觉有些茫然，这个类看起来没有问题啊，这的确属于典型的饿汉式单态模式啊，怎么会有问题呢？

是的，他看起来的确没有问题，可是如果将他 run 起来时，其结果是他不会为你正确 work。运行该类，它的执行结果是：

CODE_MAP_CACHE为空,问题在这里开始暴露.
{0=北京市}

我的程序怎么会这样？为什么在 initEnum() 方法里 CODE_MAP_CACHE 为空？为什么我输出的 CODE_MAP_CACHE 内容只有一个元素，其它两个元素呢？？？？！！

看到这里，如果是你在调试该程序，你此刻一定觉得很奇怪，难道是我的 Jvm 有问题吗？非也！如果不是，那我的程序是怎么了？这绝对不是我想要的结果。可事实上无论怎么修改 initEnum() 方法都无济于事，起码我最初是一定不会怀疑到问题可能出在创建 CachingEnumResolver 实例这一环节上。正是因为我太相信我创建 CachingEnumResolver 实例的方法，加之对 Java 类初始化与对象实例化底层原理理解有所偏差，使我为此付出了三、四个小时--约半个工作日的大好青春。

那么问题究竟出在哪里呢？为什么会出现这样的怪事呢？在解决这个问题之前，先让我们来了解一下JVM的类和对象初始化的底层机制。

回页首

类的生命周期

上图展示的是类生命周期流向；在本文里，我只打算谈谈类的"初始化"以及"对象实例化"两个阶段。

回页首

类初始化

类"初始化"阶段，它是一个类或接口被首次使用的前阶段中的最后一项工作，本阶段负责为类变量赋予正确的初始值。

Java 编译器把所有的类变量初始化语句和类型的静态初始化器通通收集到 <clinit> 方法内，该方法只能被 Jvm 调用，专门承担初始化工作。

除接口以外，初始化一个类之前必须保证其直接超类已被初始化，并且该初始化过程是由 Jvm 保证线程安全的。另外，并非所有的类都会拥有一个 <clinit>() 方法，在以下条件中该类不会拥有 <clinit>() 方法：

• 该类既没有声明任何类变量，也没有静态初始化语句；
• 该类声明了类变量，但没有明确使用类变量初始化语句或静态初始化语句初始化；
• 该类仅包含静态 final 变量的类变量初始化语句，并且类变量初始化语句是编译时常量表达式。

回页首

对象初始化

在类被装载、连接和初始化，这个类就随时都可能使用了。对象实例化和初始化是就是对象生命的起始阶段的活动，在这里我们主要讨论对象的初始化工作的相关特点。

Java 编译器在编译每个类时都会为该类至少生成一个实例初始化方法--即 "<init>()" 方法。此方法与源代码中的每个构造方法相对应，如果类没有明确地声明任何构造方法，编译器则为该类生成一个默认的无参构造方法，这个默认的构造器仅仅调用父类的无参构造器，与此同时也会生成一个与默认构造方法对应的 "<init>()" 方法.

通常来说，<init>() 方法内包括的代码内容大概为：调用另一个 <init>() 方法；对实例变量初始化；与其对应的构造方法内的代码。

如果构造方法是明确地从调用同一个类中的另一个构造方法开始，那它对应的 <init>() 方法体内包括的内容为：一个对本类的 <init>() 方法的调用；对应用构造方法内的所有字节码。

如果构造方法不是通过调用自身类的其它构造方法开始，并且该对象不是 Object 对象，那 <init>() 法内则包括的内容为：一个对父类 <init>() 方法的调用；对实例变量初始化方法的字节码；最后是对应构造子的方法体字节码。

如果这个类是 Object，那么它的 <init>() 方法则不包括对父类 <init>() 方法的调用。

回页首

类的初始化时机

本文到目前为止，我们已经大概有了解到了类生命周期中都经历了哪些阶段，但这个类的生命周期的开始阶段--类装载又是在什么时候被触发呢？类又是何时被初始化的呢？让我们带着这三个疑问继续去寻找答案。

Java 虚拟机规范为类的初始化时机做了严格定义："initialize on first active use"--" 在首次主动使用时初始化"。这个规则直接影响着类装载、连接和初始化类的机制--因为在类型被初始化之前它必须已经被连接，然而在连接之前又必须保证它已经被装载了。

在与初始化时机相关的类装载时机问题上，Java 虚拟机规范并没有对其做严格的定义，这就使得 JVM 在实现上可以根据自己的特点提供采用不同的装载策略。我们可以思考一下 Jboss AOP 框架的实现原理，它就是在对你的 class 文件装载环节做了手脚--插入了 AOP 的相关拦截字节码，这使得它可以对程序员做到完全透明化，哪怕你用 new 操作符创建出的对象实例也一样能被 AOP 框架拦截--与之相对应的 Spring AOP，你必须通过他的 BeanFactory 获得被 AOP 代理过的受管对象，当然 Jboss AOP 的缺点也很明显--他是和 JBOSS 服务器绑定很紧密的，你不能很轻松的移植到其它服务器上。嗯~……，说到这里有些跑题了，要知道 AOP 实现策略足可以写一本厚厚的书了，嘿嘿，就此打住。

说了这么多，类的初始化时机就是在"在首次主动使用时"，那么，哪些情形下才符合首次主动使用的要求呢？

首次主动使用的情形：

• 创建某个类的新实例时--new、反射、克隆或反序列化；
• 调用某个类的静态方法时；
• 使用某个类或接口的静态字段或对该字段赋值时（final字段除外）；
• 调用Java的某些反射方法时
• 初始化某个类的子类时
• 在虚拟机启动时某个含有main()方法的那个启动类。

除了以上几种情形以外，所有其它使用JAVA类型的方式都是被动使用的，他们不会导致类的初始化。

回页首

我的问题究竟出在哪里

好了，了解了JVM的类初始化与对象初始化机制后，我们就有了理论基础，也就可以理性的去分析问题了。

下面让我们来看看前面[清单一]的JAVA源代码反组译出的字节码：

public class com.ccb.framework.enums.CachingEnumResolver extends
java.lang.Object{
static {};
  Code:
   0:	new	#2; //class CachingEnumResolver
   3:	dup
   4:	invokespecial	#14; //Method "<init>":()V  ①
   7:	putstatic	#16; //Field
   SINGLE_ENUM_RESOLVER:Lcom/ccb/framework/enums/CachingEnumResolver;
   10:	new	#18; //class HashMap              ②
   13:	dup
   14:	invokespecial	#19; //Method java/util/HashMap."<init>":()V
   17:	putstatic	#21; //Field CODE_MAP_CACHE:Ljava/util/Map;  
   20:	getstatic	#21; //Field CODE_MAP_CACHE:Ljava/util/Map;  
   23:	ldc	#23; //String 0
   25:	ldc	#25; //String 北京市
   27:	invokeinterface	#31,  3; //InterfaceMethod
   java/util/Map.put:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;   ③
   32:	pop
   33:	return

private com.ccb.framework.enums.CachingEnumResolver();
  Code:
   0:	aload_0
   1:	invokespecial	#34; //Method java/lang/Object."<init>":()V
   4:	invokestatic	#37; //Method initEnums:()V                  ④
   7:	return

public static void initEnums();
  Code:
   0:	getstatic	#21; //Field CODE_MAP_CACHE:Ljava/util/Map;    ⑤
   3:	ifnonnull	24
   6:	getstatic	#44; //Field java/lang/System.out:Ljava/io/PrintStream;
   9:	ldc	#46; //String CODE_MAP_CACHE为空,问题在这里开始暴露.
   11:	invokevirtual	#52; //Method
   java/io/PrintStream.println:(Ljava/lang/String;)V
   14:	new	#18; //class HashMap
   17:	dup
   18:	invokespecial	#19; //Method java/util/HashMap."<init>":()V      ⑥
   21:	putstatic	#21; //Field CODE_MAP_CACHE:Ljava/util/Map;
   24:	getstatic	#21; //Field CODE_MAP_CACHE:Ljava/util/Map;
   27:	ldc	#54; //String 1
   29:	ldc	#25; //String 北京市
   31:	invokeinterface	#31,  3; //InterfaceMethod
   java/util/Map.put:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;   ⑦
   36:	pop
   37:	getstatic	#21; //Field CODE_MAP_CACHE:Ljava/util/Map;
   40:	ldc	#56; //String 2
   42:	ldc	#58; //String 云南省
   44:	invokeinterface	#31,  3; //InterfaceMethod
   java/util/Map.put:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;    ⑧
   49:	pop
   50:	return

public java.util.Map getCache();
  Code:
   0:	getstatic	#21; //Field CODE_MAP_CACHE:Ljava/util/Map;
   3:	invokestatic	#66; //Method
   java/util/Collections.unmodifiableMap:(Ljava/util/Map;)Ljava/util/Map;
   6:	areturn

public static com.ccb.framework.enums.CachingEnumResolver getInstance();
  Code:
   0:	getstatic	#16; 
   //Field SINGLE_ENUM_RESOLVER:Lcom/ccb/framework/enums/CachingEnumResolver;   ⑨
   3:	areturn
}

如果上面［清单一］显示，清单内容是在 JDK1.4 环境下的字节码内容，可能这份清单对于很大部分兄弟来说确实没有多少吸引力，因为这些 JVM 指令确实不像源代码那样漂亮易懂。但它的的确确是查找和定位问题最直接的办法，我们想要的答案就在这份 JVM 指令清单里。

现在，让我们对该类从类初始化到对象实例初始化全过程分析[清单一]中的代码执行轨迹。

如前面所述，类初始化是在类真正可用时的最后一项前阶工作，该阶段负责对所有类正确的初始化值，此项工作是线程安全的，JVM会保证多线程同步。

第１步：调用类初始化方法 CachingEnumResolver.<clinit>()，该方法对外界是不可见的，换句话说是 JVM 内部专用方法，<clinit>() 内包括了 CachingEnumResolver 内所有的具有指定初始值的类变量的初始化语句。要注意的是并非每个类都具有该方法，具体的内容在前面已有叙述。

第２步：进入 <clinit>() 方法内，让我们看字节码中的 "①" 行，该行与其上面两行组合起来代表 new 一个 CachingEnumResolver 对象实例，而该代码行本身是指调用 CachingEnumResolver 类的 <init>（）方法。每一个 Java 类都具有一个 <init>() 方法，该方法是 Java 编译器在编译时生成的，对外界不可见，<init>() 方法内包括了所有具有指定初始化值的实例变量初始化语句和java类的构造方法内的所有语句。对象在实例化时，均通过该方法进行初始化。然而到此步，一个潜在的问题已经在此埋伏好，就等着你来犯了。

第３步：让我们顺着执行顺序向下看，"④" 行，该行所在方法就是该类的构造器，该方法先调用父类的构造器 <init>() 对父对象进行初始化，然后调用 CachingEnumResolver.initEnum() 方法加载数据。

第４步："⑤" 行，该行获取 "CODE_MAP_CACHE" 字段值，其运行时该字段值为 null。注意，问题已经开始显现了。（作为程序员的你一定是希望该字段已经被初始化过了，而事实上它还没有被初始化）。通过判断，由于该字段为 NULL，因此程序将继续执行到 "⑥" 行，将该字段实例化为 HashMap()。

第５步：在 "⑦"、"⑧" 行，其功能就是为 "CODE_MAP_CACHE" 字段填入两条数据。

第６步：退出对象初始化方法 <init>()，将生成的对象实例初始化给类字段 "SINGLE_ENUM_RESOLVER"。（注意，此刻该对象实例内的类变量还未初始化完全，刚才由 <init>() 调用 initEnum() 方法赋值的类变量 "CODE_MAP_CACHE" 是 <clinit>() 方法还未初始化字段，它还将在后面的类初始化过程再次被覆盖）。

第７步：继续执行 <clinit>（）方法内的后继代码，"②" 行，该行对 "CODE_MAP_CACHE" 字段实例化为 HashMap 实例（注意：在对象实例化时已经对该字段赋值过了，现在又重新赋值为另一个实例，此刻，"CODE_MAP_CACHE"变量所引用的实例的类变量值被覆盖，到此我们的疑问已经有了答案）。

第8步：类初始化完毕，同时该单态类的实例化工作也完成。

通过对上面的字节码执行过程分析，或许你已经清楚了解到导致错误的深层原因了，也或许你可能早已被上面的分析过程给弄得晕头转向了，不过也没折，虽然我也可以从源代码的角度来阐述问题，但这样不够深度，同时也会有仅为个人观点、不足可信之嫌。

回页首

如何解决

要解决上面代码所存在的问题很简单，那就是将 "SINGLE_ENUM_RESOLVER" 变量的初始化赋值语句转移到 getInstance() 方法中去即可。换句话说就是要避免在类还未初始化完成时从内部实例化该类或在初始化过程中引用还未初始化的字段。

回页首

写在最后

静下浮燥之心，仔细思量自己是否真的掌握了本文主题所引出的知识，如果您觉得您已经完全或基本掌握了，那么很好，在最后，我将前面的代码稍做下修改，请思考下面两组程序是否同样会存在问题呢？

	public class CachingEnumResolver {
	public  static Map CODE_MAP_CACHE;
	static {
		CODE_MAP_CACHE = new HashMap();
		//为了说明问题,我在这里初始化一条数据
		CODE_MAP_CACHE.put("0","北京市");
		initEnums();
	}
	

	public class CachingEnumResolver {
		private static final CachingEnumResolver SINGLE_ENUM_RESOLVER;
		public  static Map CODE_MAP_CACHE;
		static {
			CODE_MAP_CACHE = new HashMap();
			//为了说明问题,我在这里初始化一条数据
			CODE_MAP_CACHE.put("0","北京市");
			SINGLE_ENUM_RESOLVER = new CachingEnumResolver();
			initEnums();
		}
	

最后，一点关于 JAVA 群体的感言：时下正是各种开源框架盛行时期，Spring 更是大行其道，吸引着一大批 JEE 开发者的眼球（我也是 fans 中的一员）。然而，让我们仔细观察一下--以 Spring 群体为例，在那么多的 Spring fans 当中，有多少人去研究过 Spring 源代码？又有多少人对 Spring 设计思想有真正深入了解呢？当然，我是没有资格以这样的口吻来说事的，我只是想表明一个观点--学东西一定要"正本清源"。

献上此文，谨以共勉。

•  log4J日志器（http://jakarta.apache.org/log4j）
• JDK1.4 Logging日志器(JDK1.4自带)
• SimpleLog日志器(把日志消息输出到标准系统错误流System.err)
• NoOpLog(不输出任何日志信息)
  
  通用日志包中的两个常用接口：LogFactory和Log，分别介绍如下：
  
  
• Log接口

通用日志包把消息分为6个级别：FATAL、ERROR、WARN、INFO、DEBUG和TRACE。其中FATAL级别最高，
TRACE级别最低。 Log接口提供输出不同级别消息的方法：

off---------------------------------最高等级的，用于关闭所有日志记录

fatal(Object message)-------输出FATAL级别的消息。

error(Object message)-------输出ERROR级别的消息。

warn(Object message)-------输出WARN级别的消息。

info(Object message)-------输出INFO级别的消息。

debug(Object message)-------输出DEBUG级别的消息。

trace(Object message)-------输出TRACE级别的消息。

all----------------------------------最低等级的，用于打开所有日志记录

注：只有当输出日志的级别大于或等于为日志配置器配置的日志级别时，这个方法才会执行。

　　如何指定日志器的日志级别，不同的日志器实现会有不同的实现方案。

• LogFactory接口

LogFactory接口提供了获得日志器实例的两个静态方法：

public static Log getLog(String name) throws LogConfigurationException;

public static Log getLog(Class class) throws LogConfigurationException;

注：name参数作为日志器的名字；class参数指定类名作为日志器名字。

　　　　
log4j简介　
　　 几乎每个大的应用程序都有它自己的日志和跟踪程序的API。顺应这一规则，E.U. SEMPER项目组决定
编写它自己的程序跟踪API（tracing API）。这开始于1996年早期。经过无数的工作，更改和性能加强，这
个API终于成为一个十分受欢迎的Java日志软件包，那就是log4j。这个软件包的发行遵守open source动议认
证的Apache Software License。最新的log4j版本包括全部的源代码，类文件和文档资料，
可以在 http://logging.apache.org/log4j/找到它们。另外，log4j已经被转换成 C, C++, C#, Perl, Python, 
Ruby, 和 Eiffel 语言。
　　
　 　Log4j是Apache的一个开放源代码项目，通过使用Log4j，我们可以控制日志信息输送的目的地是控制台、
文件、GUI组件、甚至是套接口服务 器、NT的事件记录器、UNIX Syslog守护进程等；我们也可以控制每一条
日志的输出格式；通过定义每一条日志信息的级别，我们能够更加细致地控制日志的生成过程。最令人感兴趣
的就 是，这些可以通过一个配置文件来灵活地进行配置，而不需要修改应用的代码。
　　
　　

log4j三个组件

       通常，我们都提供一个名为 log4j.properties的文件，在第一次调用到Log4J时，Log4J会在类路径
（../web-inf/class/当然也可以放到其它任何目录，只要该目录被包含到类路径中即可）中定位这个文件，并读入
这个文件完成的配置。这个配置文件告 诉Log4J以什么样的格式、把什么样的信息、输出到什么地方。
　　 Log4j有三个主要的组件：Loggers(记录器)，Appenders(输出源)和Layouts(布局)，这里可简单理解为日志
类别，日志要输出的地方和日志以何种形式输出。综合使用这三个组件可以轻松的记录信息的类型和级别，并可
以在运行时控制日志输出的样式和位置。下面对三个组件分别进行说明：
　　
　　 1、 Loggers
　 　Loggers组件在此系统中被分为五个级别：DEBUG、INFO、WARN、ERROR和FATAL。这五个级别是有顺序
的，DEBUG < INFO < WARN < ERROR < FATAL，分别用来指定这条日志信息的重要程度,明白这一点很重要，
这里Log4j有一个规则：假设Loggers级别为P，如果在Loggers中发生了一个级别Q比P高，则可以启动，否则屏蔽掉。
假设你定义的级别是info，那么error和warn的日志可以显示而比他低的debug信息就不显示了。
 　
　　 Java程序举例来说：
　　
　　 //建立Logger的一个实例，命名为“com.foo”
　　　 Logger　logger = Logger.getLogger("com.foo"); //"com.foo"是实例进行命名，也可以任意
　　 //设置logger的级别。通常不在程序中设置logger的级别。一般在配置文件中设置。
　　 logger.setLevel(Level.INFO);
　　 Logger barlogger = Logger.getLogger("com.foo.Bar");
　　 //下面这个请求可用，因为WARN >= INFO
　　 logger.warn("Low fuel level.");
　　 //下面这个请求不可用，因为DEBUG < INFO
　　 logger.debug("Starting search for nearest gas station.");
　　 //命名为“com.foo.bar”的实例barlogger会继承实例“com.foo”的级别。因此，下面这个请求可用，因为INFO >= INFO
　　 barlogger.info("Located nearest gas station.");
　　 //下面这个请求不可用，因为DEBUG < INFO
　　 barlogger.debug("Exiting gas station search");
　　 这里“是否可用”的意思是能否输出Logger信息。
　　　　 在对Logger实例进行命名时，没有限制，可以取任意自己感兴趣的名字。一般情况下建议以类的所在位置来
命名Logger实例，这是目前来讲比较有效的Logger命名方式。这样可以使得每个类建立自己的日志信息，便于管理。
比如：
　　
　　 static Logger logger = Logger.getLogger(ClientWithLog4j.class.getName());
　　
　 　2、Appenders
　　禁用与使用日志请求只是Log4j其中的一个小小的地方，Log4j日志系统允许把日志输出到不同的地方，
如控制台（Console）、文件（Files）、根据天数或者文件大小产生新的文件、以流的形式发送到其它地方等等。
　　
　　 其语法表示为：
　　
　　 org.apache.log4j.ConsoleAppender（控制台）
　　 org.apache.log4j.FileAppender（文件）
　　 org.apache.log4j.DailyRollingFileAppender（每天产生一个日志文件）
       org.apache.log4j.RollingFileAppender（文件大小到达指定尺寸的时候产生一个新的文件）
　　 org.apache.log4j.WriterAppender（将日志信息以流格式发送到任意指定的地方）
　　
　　 配置时使用方式为：
　　 log4j.appender.appenderName = fully.qualified.name.of.appender.class
　　 log4j.appender.appenderName.option1 = value1
　　 …
       log4j.appender.appenderName.option = valueN
　　 这样就为日志的输出提供了相当大的便利。
　　
　　3、Layouts
　 　有时用户希望根据自己的喜好格式化自己的日志输出。Log4j可以在Appenders的后面附加Layouts来完成
      这个功能。Layouts提供了 四种日志输出样式，如根据HTML样式、自由指定样式、包含日志级别与信息的样式
      和包含日志时间、线程、类别等信息的样式等等。
　　
　　 其语法表示为：
　　
　　 org.apache.log4j.HTMLLayout（以HTML表格形式布局），
　　 org.apache.log4j.PatternLayout（可以灵活地指定布局模式），
　　 org.apache.log4j.SimpleLayout（包含日志信息的级别和信息字符串），
　　 org.apache.log4j.TTCCLayout（包含日志产生的时间、线程、类别等等信息）
　　
　　 配置时使用方式为：
　　
　　 log4j.appender.appenderName.layout =fully.qualified.name.of.layout.class
　　 log4j.appender.appenderName.layout.option1 = value1
　　 …
　　 log4j.appender.appenderName.layout.option = valueN

log4j基本编程方法
　　
　　 以上是从原理方面说明Log4j的使用方法，在具体Java编程使用Log4j可以参照以下示例：
　　
　　 1、 建立Logger实例：
　　 语法表示：public static Logger getLogger( String name)
　　 实际使用：static Logger logger = Logger.getLogger(ServerWithLog4j.class.getName ()) ;
　　
　　 2、 读取配置文件：
　　 获得了Logger的实例之后，接下来将配置Log4j使用环境：
　　 语法表示：
　　 BasicConfigurator.configure()：自动快速地使用缺省Log4j环境。
　　 PropertyConfigurator.configure(String configFilename)：读取使用Java的特性文件编写的配置文件。
　　 DOMConfigurator.configure(String filename)：读取XML形式的配置文件。
　　 实际使用：
    PropertyConfigurator.configure("ServerWithLog4j.properties");
　　
　　 3、 插入日志信息
　　 完成了以上连个步骤以后，下面就可以按日志的不同级别插入到你要记录日志的任何地方了。
　　 语法表示：
　　 Logger.debug(Object message);//调试信息
　　 Logger.info(Object message);//一般信息
　　 Logger.warn(Object message);//警告信息
　　 Logger.error(Object message);//错误信息
　　 Logger.fatal(Object message);//致命错误信息

　　实际使用：logger.info("ServerSocket before accept: " + server);
　　
log4j配置文件

　在实际编程时，要使Log4j真正在系统中运行事先还要对配置文件进行定义。定义步骤就是对Logger、
Appender及Layout的分别使用。
    Log4j支持两种配置文件格式，一种是XML格式的文件，一种是java properties（key=value）
【Java特性文件（键=值）】。下面我们介绍使用Java特性文件做为配置文件的方法
   具体如下：
　　
　　 1、配置根Logger，其语法为：
　　 log4j.rootLogger = [ level ] , appenderName1, appenderName2, …
         level : 是日志记录的优先级，分为OFF、FATAL、ERROR、WARN、INFO、DEBUG、ALL或者您定义的级别。
Log4j建议只使用四个级别，优先级从高到低分别是ERROR、WARN、INFO、DEBUG。通过在这里定义的级别，
您可以控制到应用程序中相应级别的日志信息的开关。比如在这里定 义了INFO级别，则应用程序中所有DEBUG级
别的日志信息将不被打印出来。
　　      appenderName:就是指定日志信息输出到哪个地方。您可以同时指定多个输出目的地。
   例如：log4j.rootLogger＝info,A1,B2,C3
　　
　　 2、配置日志信息输出目的地，其语法为：
　　 log4j.appender.appenderName = fully.qualified.name.of.appender.class  //
　　   "fully.qualified.name.of.appender.class" 可以指定下面五个目的地中的一个：
          1.org.apache.log4j.ConsoleAppender（控制台）
          2.org.apache.log4j.FileAppender（文件）
          3.org.apache.log4j.DailyRollingFileAppender（每天产生一个日志文件）
          4.org.apache.log4j.RollingFileAppender（文件大小到达指定尺寸的时候产生一个新的文件）
          5.org.apache.log4j.WriterAppender（将日志信息以流格式发送到任意指定的地方）
             1.ConsoleAppender选项
                    Threshold=WARN:指定日志消息的输出最低层次。
                    ImmediateFlush=true:默认值是true,意谓着所有的消息都会被立即输出。
                    Target=System.err：默认情况下是：System.out,指定输出控制台
              2.FileAppender 选项
                    Threshold=WARN:指定日志消息的输出最低层次。
                    ImmediateFlush=true:默认值是true,意谓着所有的消息都会被立即输出。
                    File=mylog.txt:指定消息输出到mylog.txt文件。
                    Append=false:默认值是true,即将消息增加到指定文件中，false指将消息覆盖指定的文件内容。
            3.DailyRollingFileAppender 选项
                    Threshold=WARN:指定日志消息的输出最低层次。
                    ImmediateFlush=true:默认值是true,意谓着所有的消息都会被立即输出。
                    File=mylog.txt:指定消息输出到mylog.txt文件。
                    Append=false:默认值是true,即将消息增加到指定文件中，false指将消息覆盖指定的文件内容。
                    DatePattern='.'yyyy-ww:每周滚动一次文件，即每周产生一个新的文件。当然也可以指定按月、周、
                        天、时和分。即对应的格式如下：
                    1)'.'yyyy-MM: 每月
                    2)'.'yyyy-ww: 每周 
                    3)'.'yyyy-MM-dd: 每天
                    4)'.'yyyy-MM-dd-a: 每天两次
                    5)'.'yyyy-MM-dd-HH: 每小时
                    6)'.'yyyy-MM-dd-HH-mm: 每分钟
            4.RollingFileAppender 选项
                    Threshold=WARN:指定日志消息的输出最低层次。
                    ImmediateFlush=true:默认值是true,意谓着所有的消息都会被立即输出。
                    File=mylog.txt:指定消息输出到mylog.txt文件。
                    Append=false:默认值是true,即将消息增加到指定文件中，false指将消息覆盖指定的文件内容。
                    MaxFileSize=100KB: 后缀可以是KB, MB 或者是 GB. 在日志文件到达该大小时，将会自动滚动，即将原来
                    的内容移到mylog.log.1文件。
                    MaxBackupIndex=2:指定可以产生的滚动文件的最大数。

实际应用：
　　 log4j.appender.A1=org.apache.log4j.ConsoleAppender //这里指定了日志输出的第一个位置A1是控制台ConsoleAppender

╭=========================================╮
    青山不改 绿水长流http://blog.csdn.net/wangyihust
      欢迎各位转贴，但需声明版权，尊重技术原创性 :)
       E-mail:wangyihust@163.com    OICQ:76406573   
╰=========================================╯
　　
　　 3、配置日志信息的格式，其语法为：
　　 1).log4j.appender.appenderName.layout = fully.qualified.name.of.layout.class
              "fully.qualified.name.of.layout.class" 可以指定下面4个格式中的一个：
               1.org.apache.log4j.HTMLLayout（以HTML表格形式布局），
　　        2.org.apache.log4j.PatternLayout（可以灵活地指定布局模式），
　　        3.org.apache.log4j.SimpleLayout（包含日志信息的级别和信息字符串），
　　        4.org.apache.log4j.TTCCLayout（包含日志产生的时间、线程、类别等等信息）
                   1.HTMLLayout 选项
                      LocationInfo=true:默认值是false,输出java文件名称和行号
                      Title=my app file: 默认值是 Log4J Log Messages.
                   2.PatternLayout 选项
                      ConversionPattern=%m%n :指定怎样格式化指定的消息。
                   3.XMLLayout  选项
                      LocationInfo=true:默认值是false,输出java文件和行号
   实际应用：
   　　log4j.appender.A1.layout=org.apache.log4j.PatternLayout

       2). log4j.appender.A1.layout.ConversionPattern=%-4r %-5p %d{yyyy-MM-dd HH:mm:ssS} %c %m%n
           这里需要说明的就是日志信息格式中几个符号所代表的含义：
　　          －X号: X信息输出时左对齐；
                   %p: 输出日志信息优先级，即DEBUG，INFO，WARN，ERROR，FATAL,
                   %d: 输出日志时间点的日期或时间，默认格式为ISO8601，也可以在其后指定格式，
比如：%d{yyy MMM dd HH:mm:ss,SSS}，输出类似：2002年10月18日 22：10：28，921
                   %r: 输出自应用启动到输出该log信息耗费的毫秒数
                   %c: 输出日志信息所属的类目，通常就是所在类的全名
                   %t: 输出产生该日志事件的线程名
                   %l: 输出日志事件的发生位置，相当于%C.%M(%F:%L)的组合,包括类目名、发生的线程，以及在代码
中的行数。举例：Testlog4.main(TestLog4.java:10)
                   %x: 输出和当前线程相关联的NDC(嵌套诊断环境),尤其用到像java servlets这样的多客户多线程的应用中。
                   %%: 输出一个"%"字符
                   %F: 输出日志消息产生时所在的文件名称
                   %L: 输出代码中的行号
                   %m: 输出代码中指定的消息,产生的日志具体信息
                   %n: 输出一个回车换行符，Windows平台为"\r\n"，Unix平台为"\n"输出日志信息换行
            可以在%与模式字符之间加上修饰符来控制其最小宽度、最大宽度、和文本的对齐方式。如：
                     1)%20c：指定输出category的名称，最小的宽度是20，如果category的名称小于20的话，默认的情况下右对齐。
                     2)%-20c:指定输出category的名称，最小的宽度是20，如果category的名称小于20的话，"-"号指定左对齐。
                     3)%.30c:指定输出category的名称，最大的宽度是30，如果category的名称大于30的话，就会将左边
多出的字符截掉，但小于30的话也不会有空格。
                     4)%20.30c:如果category的名称小于20就补空格，并且右对齐，如果其名称长于30字符，
就从左边交远销出的字符截掉。

　　这里上面三个步骤是对前面Log4j组件说明的一个简化；下面给出一个具体配置例子，在程序中可以参照执行：
　　 log4j.rootLogger=INFO,A1，B2
　　 log4j.appender.A1=org.apache.log4j.ConsoleAppender
　　 log4j.appender.A1.layout=org.apache.log4j.PatternLayout
　　 log4j.appender.A1.layout.ConversionPattern=%-4r %-5p %d{yyyy-MM-dd HH:mm:ssS} %c %m%n
 　　根据上面的日志格式，某一个程序的输出结果如下：
　　 0　　INFO　2003-06-13 13:23:46968 ClientWithLog4j Client socket:
Socket[addr=localhost/127.0.0.1,port=8002,localport=2014]
         16　 DEBUG 2003-06-13 13:23:46984 ClientWithLog4j Server says:
'Java server with log4j, Fri Jun 13 13:23:46 CST 2003'
　　 16　 DEBUG 2003-06-13 13:23:46984 ClientWithLog4j GOOD
　　 16　 DEBUG 2003-06-13 13:23:46984 ClientWithLog4j Server responds: 'Command 'HELLO' not understood.'
　　 16　 DEBUG 2003-06-13 13:23:46984 ClientWithLog4j HELP
　　 16　 DEBUG 2003-06-13 13:23:46984 ClientWithLog4j Server responds: 'Vocabulary: HELP QUIT'
　　 16　 DEBUG 2003-06-13 13:23:46984 ClientWithLog4j QUIT
 
      4. 当输出信息于回滚文件时

          log4j.appender.ROLLING_FILE=org.apache.log4j.RollingFileAppender   //指定以文件的方式输出日志
           log4j.appender.ROLLING_FILE.Threshold=ERROR 
           log4j.appender.ROLLING_FILE.File=rolling.log  //文件位置,也可以用变量、rolling.log
           log4j.appender.ROLLING_FILE.Append=true 
           log4j.appender.ROLLING_FILE.MaxFileSize=10KB  //文件最大尺寸
           log4j.appender.ROLLING_FILE.MaxBackupIndex=1  //备份数
           log4j.appender.ROLLING_FILE.layout=org.apache.log4j.PatternLayout 
           log4j.appender.ROLLING_FILE.layout.ConversionPattern=[framework] %d - %c -%-4r [%t] %-5p %c %x - %m%n  　　

         5.Log4J对应用性能的影响

         如果在程序运行中输出大量日志，显然会对应用的性能造成一定的影响。Log4J对性能的影响取决于以下因素：

• 日志输出目的地：输出到控制台的速度和输出到文件系统的速度是不一样的。
• 日志输出格式：格式简单，速度也更快。
• 日志级别：日志级别设置的越低，输出的日志内容越多，对性能的影响也越大。

log4j全能配置文件(转自gmmgood)

 使用XML配置文件

首先，看看下面的XML配置文件示例：

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/">
       
  <appender name="ConsoleAppender" class="org.apache.log4j.ConsoleAppender">
    <layout class="org.apache.log4j.SimpleLayout"/>
  </appender>
  <root>
    <priority value ="debug" />
    <appender-ref ref="ConsoleAppender"/>
  </root>
</log4j:configuration>
   
 

文件以标准的XML声明作为开始，后面跟着指出DTD（文档类型定义）的DOCTYPE声明，它定义了XML文件的结构，
例如，什么元素可以嵌入在其他元素中等等。上面文件在log4j发行版的src/java/org/apache/log4j/xml目录中。
接着看看封装所有元素的 log4j:configuration 元素，它在DOCTYPE声明中被指定为根元素。嵌入在根元素中有两个结构：

  <appender name="ConsoleAppender" class="org.apache.log4j.ConsoleAppender">
    <layout class="org.apache.log4j.SimpleLayout"/>
  </appender>     
   
 

这里创建一个名叫"ConsoleAppender"的 Appender，注意，你可以选择任何名字，该示例之所以选择"ConsoleAppender"，
完全是为了示例的设计。接着这个appender类以全名形式给出，经常用规范（fully qualified）类名。 Appender必须具有
一个指定的 name和class。嵌入在 Appender之内的是 layout元素，这里它被指定为SimpleLayout。 Layout 必须具
有一个 class属性。

  <root>
    <priority value ="debug" />
    <appender-ref ref="ConsoleAppender"/>
  </root>      
   

root元素必须存在且不能被子类化。示例中的优先级被设置为"debug"，设置appender饱含一个appender-ref元素。
还有更多的属性或元素可以指定。查看log4j发行版中的src/java/org/apache/log4j/xml/log4j.dtd以了解关于XML配置
文件结构的更多信息。可以用下面这种方法把配置信息文件读入到Java程序中:

DOMConfigurator.configure("configurationfile.xml");   

DOMConfigurator 用一棵DOM树来初始化log4j环境。这里是示例中的XML配置文件：configurationfile.xml。这里是
执行该配置文件的java程序:

import org.apache.log4j.Logger;
import org.apache.log4j.xml.DOMConfigurator;
public class externalxmltest {
   static Logger logger = Logger.getLogger(filetest.class);
   public static void main(String args[]) {
      DOMConfigurator.configure("xmllog4jconfig.xml");
      logger.debug("Here is some DEBUG");
      logger.info("Here is some INFO");
      logger.warn("Here is some WARN");
      logger.error("Here is some ERROR");
      logger.fatal("Here is some FATAL");
   }
}
   

对于带有PatternLayout的FileAppender的日志记录器Logger的XML配置文件:

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/">
       
  <appender name="appender" class="org.apache.log4j.FileAppender">
    <param name="File" value="Indentify-Log.txt"/>
    <param name="Append" value="true"/>
    <layout class="org.apache.log4j.PatternLayout">
      <param name="ConversionPattern" value="%d [%t] %p - %m%n"/>
    </layout>
  </appender>
  <root>
    <priority value ="info"/>
    <appender-ref ref="appender"/>
  </root>
</log4j:configuration>
   

 log4j日志写入数据库

首先创建一数据库表:

log4j.properties如下配置:

log4j.rootLogger=DEBUG,CONSOLE,DATABASE

import sun.jdbc.odbc.*;
import java.sql.*;

import org.apache.log4j.Category;
import org.apache.log4j.Level;
import org.apache.log4j.Logger;
import org.apache.log4j.PropertyConfigurator;
import org.apache.log4j.jdbc.*;

public class Write2Database{
  public static void main(String[] args){
    static Logger logger = Logger.getLogger
            ( write2database.class.getName () ) ;

    PropertyConfigurator.configure ( "log4j2database.properties" ) ;

    logger.info ( "test" ) ;
  }
}

运行起来，你就会看到有这样的sql语句被执行了：
       INSERT INTO jws_log  VALUES ('2006-01-18 17:50:22', 'main', 'INFO',
'Wite2Database.main(Write2Database.java:18)', 'test', '')

注意 ：在赛迪论坛上有一个笔者按照上述类似的方法没有运行成功，现将他所出现的问题和解决方法转载。

上述方法是利用传统的数据库连接方法，对于数据库的管理和效率严重不足，在现在这个连接池横行的时代,
为什么我们不能给给Log4j配上连接池，让Log4j利用数据连接池的连接和数据库进行通讯。
现查看Log4j的Api,发现JDBCAppender这个类有以下几段话：WARNING: This version of JDBCAppender is very
likely to be completely replaced in the future. Moreoever, it does not log exceptions. The JDBCAppender
provides for sending log events to a database.

For use as a base class:

• Override getConnection() to pass any connection you want. Typically this is used to enable
  application wide connection pooling.
• Override closeConnection(Connection con) -- if you override getConnection make sure to
  implement closeConnection to handle the connection you generated. Typically this would
  return the connection to the pool it came from.
• Override getLogStatement(LoggingEvent event) to produce specialized or dynamic statements.
  The default uses the sql option value.

原来log4j建议我们把其提供的JDBCAppender作为基类来使用，然后Override三个父类的方法：getConnection(),
closeConnection(Connection con)和getLogStatement(LoggingEvent event)。

原来如此，那就写一个子类JDBCPoolAppender来替代这个JDBCAppender
　　
　　 JDBCPoolAppender代码和其相关代码如下：
　　
　　 JDBCPoolAppender.java:
　　
　　 package common.log;
　　 import java.sql.Connection;
　　 import org.apache.log4j.spi.LoggingEvent;
　　 import java.sql.SQLException;
　　 import java.sql.Statement;
　　 import java.util.Iterator;
　　 import org.apache.log4j.spi.ErrorCode;
　　 import org.apache.log4j.PatternLayout;
　　 import common.sql.MyDB;
　　 import common.sql.GeneralDb;
　　
　　 public class JDBCPoolAppender extends org.apache.log4j.jdbc.JDBCAppender {
　　
　　 private MyDB mydb = null;
　　 protected String sqlname=""; //增加一个数据库jndiName的属性
　　
　　 protected Connection connection = null;
　　 protected String sqlStatement = "";
　　 /**
　　 * size of LoggingEvent buffer before writting to the database.
　　 * Default is 1.
　　 */
　　 protected int bufferSize = 1;
　　
　　 public JDBCPoolAppender() {
　　 super();
　　 }
　　
　　 /**
　　 * ArrayList holding the buffer of Logging Events.
　　 */
　　 public void append(LoggingEvent event) {
　　 buffer.add(event);
　　 if (buffer.size() >= bufferSize)
　　 flushBuffer();
　　 }
　　
　　 /**
　　 * By default getLogStatement sends the event to the required Layout object.
　　 * The layout will format the given pattern into a workable SQL string.
　　 *
　　 * Overriding this provides direct access to the LoggingEvent
　　 * when constructing the logging statement.
　　 *
　　 */
　　 protected String getLogStatement(LoggingEvent event) {
　　 return getLayout().format(event);
　　 }
　　
　　 /**
　　 *
　　 * Override this to provide an alertnate method of getting
　　 * connections (such as caching).　One method to fix this is to open
　　 * connections at the start of flushBuffer() and close them at the
　　 * end.　I use a connection pool outside of JDBCAppender which is
　　 * accessed in an override of this method.
　　 * */
　　 protected void execute(String sql) throws SQLException {
　　 Connection con = null;
　　 Statement stmt = null;
　　 try {
　　 con = getConnection();
　　 stmt = con.createStatement();
　　 stmt.executeUpdate(sql);
　　 } catch (SQLException e) {
　　 if (stmt != null)
　　 stmt.close();
　　 throw e;
　　 }
　　 stmt.close();
　　 closeConnection(con);
　　 //System.out.println("Execute: " + sql);
　　 }
　　
　　 /**
　　 * Override this to return the connection to a pool, or to clean up the
　　 * resource.
　　 *
　　 * The default behavior holds a single connection open until the appender
　　 * is closed (typically when garbage collected).
　　 */
　　 protected void closeConnection(Connection con) {
　　 mydb=null;
　　 try {
　　 if (connection != null && !connection.isClosed())
　　 connection.close();
　　 } catch (SQLException e) {
　　 errorHandler.error("Error closing connection", e,
　　 ErrorCode.GENERIC_FAILURE);
　　 }
　　
　　 }
　　
　　 /**
　　 * Override 此函数来利用连接池返回一个Connetion对象
　　 *
　　 */
　　 protected Connection getConnection() throws SQLException {
　　 try {
　　 mydb = GeneralDb.getInstance(sqlname);
　　 connection = mydb.getConnection();
　　 } catch (Exception e) {
　　 errorHandler.error("Error opening connection", e, ErrorCode.GENERIC_FAILURE);
　　 }
　　 return connection;
　　 }
　　
　　 /**
　　 * Closes the appender, flushing the buffer first then closing the default
　　 * connection if it is open.
　　 */
　　 public void close() {
　　 flushBuffer();
　　
　　 try {
　　 if (connection != null && !connection.isClosed())
　　 connection.close();
　　 } catch (SQLException e) {
　　 errorHandler.error("Error closing connection", e,
　　 ErrorCode.GENERIC_FAILURE);
　　 }
　　 this.closed = true;
　　 }
　　
　　 /**
　　 * loops through the buffer of LoggingEvents, gets a
　　 * sql string from getLogStatement() and sends it to execute().
　　 * Errors are sent to the errorHandler.
　　 *
　　 * If a statement fails the LoggingEvent stays in the buffer!
　　 */
　　 public void flushBuffer() {
　　 //Do the actual logging
　　 removes.ensureCapacity(buffer.size());
　　 for (Iterator i = buffer.iterator(); i.hasNext(); ) {
　　 try {
　　 LoggingEvent logEvent = (LoggingEvent) i.next();
　　 String sql = getLogStatement(logEvent);
　　 execute(sql);
　　 removes.add(logEvent);
　　 } catch (SQLException e) {
　　 errorHandler.error("Failed to excute sql", e,
　　 ErrorCode.FLUSH_FAILURE);
　　 }
　　 }
　　
　　 // remove from the buffer any events that were reported
　　 buffer.removeAll(removes);
　　
　　 // clear the buffer of reported events
　　 removes.clear();
　　 }
　　
　　 /** closes the appender before disposal */
　　 public void finalize() {
　　 close();
　　 }
　　
　　 /**
　　 * JDBCAppender requires a layout.
　　 * */
　　 public boolean requiresLayout() {
　　 return true;
　　 }
　　
　　 /**
　　 *
　　 */
　　 public void setSql(String s) {
　　 sqlStatement = s;
　　 if (getLayout() == null) {
　　 this.setLayout(new PatternLayout(s));
　　 } else {
　　 ((PatternLayout) getLayout()).setConversionPattern(s);
　　 }
　　 }
　　
　　 /**
　　 * Returns pre-formated statement eg: insert into LogTable (msg) values ("%m")
　　 */
　　 public String getSql() {
　　 return sqlStatement;
　　 }
　　
　　 public void setSqlname(String sqlname){
　　 sqlname=sqlname;
　　 }
　　
　　 public String getSqlname(){
　　 return sqlname;
　　 }
　　
　　 public void setBufferSize(int newBufferSize) {
　　 bufferSize = newBufferSize;
　　 buffer.ensureCapacity(bufferSize);
　　 removes.ensureCapacity(bufferSize);
　　 }
　　
　　 public int getBufferSize() {
　　 return bufferSize;
　　 }
　　 }
　　
　　 MyDB.java:
　　 package common.sql;
　　 import java.sql.*;
　　 import com.codestudio.sql.*;　//引入开源项目Poolman数据库连接池的包
　　
　　 public class MyDB {
　　 public static final String module = MyDB.class.getName();
　　 private String dbName = "";
　　 private PoolMan plmn = null;
　　
　　 public MyDB(String dbName) {
　　 try {
　　 if (plmn == null) {
　　 plmn = (PoolMan) Class.forName("com.codestudio.sql.PoolMan").
　　 newInstance();
　　 }
　　 } catch (Exception ec) {
　　 System.out.println(ec.toString()+module);
　　 }
　　 this.dbName = dbName;
　　 }
　　
　　 private Connection getNewConnection() {
　　 Connection conn = null;
　　 try {
　　 conn = plmn.connect("jdbc:poolman://" + dbName);
　　 conn.setAutoCommit(true);
　　 } catch (Exception ec) {
　　 System.out.println(ec.toString()+"First:Connect sqlsever failed"+module);
　　 try {
　　 Thread.sleep(1000);
　　 conn = plmn.connect("jdbc:poolman://" + dbName);
　　 conn.setAutoCommit(true);
　　 } catch (Exception ecs) {
　　 System.out.println(ecs.toString()+"Again:Connect sqlsever faile"+module);
　　 }
　　 }
　　 return conn;
　　 }
　　
　　 public Connection getConnection() {
　　 return getNewConnection();
　　 }
　　 }
　　 GeneralDb.java:
　　
　　 package common.sql;
　　
　　 package common.sql;
　　 import java.util.*;
　　
　　 public class GeneralDb {
　　 private static Hashtable dbPool;
　　 public static MyDB getInstance(String dbname) {
　　 if (dbPool == null) {
　　 dbPool = new Hashtable();
　　 }
　　 MyDB db = (MyDB) dbPool.get(dbname);
　　 if (db == null) {
　　 db = new MyDB(dbname);
　　 dbPool.put(dbname, db);
　　 }
　　 return db;
　　 }
　　 }
　　
　　 Log4j数据库连接池的配置如下：
　　 log4j.appender.JDBC=common.log.JDBCPoolAppender
　　 log4j.appender.JDBC.sqlname=log
　　 log4j.appender.JDBC.layout=org.apache.log4j.PatternLayout
　　 log4j.appender.JDBC.sql=INSERT INTO LOGGING (log_date, log_level,
location, message) VALUES ('%d{ISO8601}', '%-5p', '%C,%L', '%m')
　　
　　 poolman.xml配置如下：
　　
　　 〈?xml version="1.0" encoding="UTF-8"?>
　　 〈poolman>
　　 〈management-mode>local〈/management-mode>
　　 〈datasource>
　　 〈dbname>log〈/dbname>
　　 〈jndiName>log〈/jndiName>
　　 〈driver>com.mysql.jdbc.Driver〈/driver>
　　 〈url>jdbc:mysql://localhost:3306/test〈/url>
　　 〈username>use〈/username>
　　 〈password>password〈/password>
　　 〈minimumSize>0〈/minimumSize>
　　 〈maximumSize>10〈/maximumSize>
　　 〈logFile>logs/mysql.log〈/logFile>
　　 〈/datasource>　　
　　 〈/poolman>

   运行成功！对于JDBCPoolAppender的属性（比如sqlname属性）我们可以利用Log4j的反射机
制随便添加，只要在配置文件给其附上值即可应用，而原来的父类里面的一些属性（username
什么的)和其get,set方法由于在连接池中不需要，所以删除。而在JDBCPoolAppender类中，我也
只是将getConnection 方法Override ，在这个方法中我们可以根据需要生成我们的Connection
对象，另外两个方法大家可以根据需求来决定怎样Override。

 Log4Net  for .net framework

     等待研究  

       用户可以从http://logging.apache.org/log4net/下载log4net的源代码。解压软件包后，在解压的src目录
下将log4net.sln载入Visual Studio .NET，编译后可以得到log4net.dll。用户要在自己的程序里加入日志功能，
只需将log4net.dll引入工程即可。  

hibernate中session.delete(sql),3.1与2.0的区别,导致的错误

今天使用session.delete(sql);报下面的错误:

 

org.hibernate.MappingException: Unknown entity: java.lang.String
 at org.hibernate.impl.SessionFactoryImpl.getEntityPersister(SessionFactoryImpl.java:569)
 at org.hibernate.impl.SessionImpl.getEntityPersister(SessionImpl.java:1086)
 at org.hibernate.event.def.DefaultDeleteEventListener.onDelete(DefaultDeleteEventListener.java:63)
 at org.hibernate.impl.SessionImpl.delete(SessionImpl.java:579)

 

查查终于知道原因:

 

    session.delete(sql)是2.0的接口,3.1中已经废弃,同时废弃的有:
    find()、iterate()、filter()和delete(String hqlSelectQuery),saveOrUpdateCopy()

 

  如果要使用的话,可以采用以下方式创建Session实例： 

      org.hibernate.classic.Session session=sessionFactory.openSession(); 

 

      org.hibernate.classic.Session保留了2.0的接口

 

下面是3.1的reference里面这样写的,我使用了,但是还是报错,郁闷:

 

1) Hibernate3.0执行批量删除的程序代码： 
Session session = sessionFactory.openSession(); 
Transaction tx = session.beginTransaction(); 
String hqlDelete = "delete Customer where name = :oldName"; 
int deletedEntities = s.createQuery( hqlDelete ) 
.setString( "oldName", oldName ) 
.executeUpdate(); 
tx.commit(); 
session.close();

 

2)Hibernate3.0执行批量更新的程序代码： 
Session session = sessionFactory.openSession(); 
Transaction tx = session.beginTransaction(); 
String hqlUpdate = "update Customer set name = :newName where name = :oldName"; 
int updatedEntities = s.createQuery( hqlUpdate ) 
.setString( "newName", newName ) 
.setString( "oldName", oldName ) 
.executeUpdate(); 
tx.commit(); 
session.close(); 

 

我按照上面的写法,运行后报错如下:

org.hibernate.QueryException: query must begin with SELECT or FROM: delete [delete Resource r where r.nodeId=:nodeId and r.devId is not null ]
 at org.hibernate.hql.classic.ClauseParser.token(ClauseParser.java:83)
 at org.hibernate.hql.classic.PreprocessingParser.token(PreprocessingParser.java:108)
 at org.hibernate.hql.classic.ParserHelper.parse(ParserHelper.java:28)
 at org.hibernate.hql.classic.QueryTranslatorImpl.compile(QueryTranslatorImpl.java:176)
 at org.hibernate.hql.classic.QueryTranslatorImpl.compile(QueryTranslatorImpl.java:152)
 at org.hibernate.impl.SessionFactoryImpl.getQuery(SessionFactoryImpl.java:427)
 at org.hibernate.impl.SessionImpl.getQueries(SessionImpl.java:884)
 at org.hibernate.impl.SessionImpl.executeUpdate(SessionImpl.java:865)
 at org.hibernate.impl.QueryImpl.executeUpdate(QueryImpl.java:89)

昨天的问题解决了

又把hibernate3的手册仔细的看了一遍,确认自己的写法是没错的,然后又上hibernate的论坛,几乎没有人有我的这个问题,这才想到是不是同事在hibernate.hbm.xml中设置了什么参数,使得我不能使用3.0的特性呢?

      看了,果真如此,郁闷哦~

     里面有一句:

     <property name="hibernate.query.factory_class">org.hibernate.hql.classic.ClassicQueryTranslatorFactory</property>

     这样就使用了2.0的接口.郁闷啊.

     把这句去掉就OK了.

 

     附:

      因为使用了中文拼装的hql后,中文会变成问号,大致如下:

 

      String hql="from user u where u.name like %"+userName+"%";

 

      3.0版本是:

      Query query = session.createQuery("from user u where u.name like :username").setString("username",userName);

现在要通过一个主键id去数据库中删除对应的一条记录，我该怎样做？如果是将参数delId传递进来的话，那该怎么处理？ 我这样做的，但是报了错 public void delfun(String delId) throws DatastoreException { Session session = HibernateUtil.getSession(); Transaction tx = null; try{ tx = session.beginTransaction(); Info info = (Info)session.load(Info.class,id); //出错行 session.delete(delId); tx.commit(); } catch(Exception ex) { HibernateUtil.rollbackTransaction(tx); throw DatastoreException.datastoreError(ex); } finally { HibernateUtil.closeSession(session); } } 错误信息为： com.framework.exceptions.DatastoreException.datastoreError(DatastoreException.java:28) com.service.NpisServiceImpl.delGyinfo(NpisServiceImpl.java:131)

	回复人：pdvv(我爱花猫)	2006-3-1 17:32:22	得分:0
?	你给出的异常应该属于你自己框架的信息吧，没有多少参考价值。 使用Session.load()要确保数据一定存在，还是用get()吧； 或者直接session.delete("from INFO where ID = 1");
Top

	回复人：yuanjian0211(元剑)	2006-3-1 17:46:04	得分:0
?	错误提示信息为： Hibernate: select gyinfo0_.id as id0_, info0_.userid as userid0_, info0_.tit le as title0_,info0_.descript as descript0_ from Info info0_ where info0_.id=? 请指点
Top

	回复人：yuanjian0211(元剑)	2006-3-1 17:56:29	得分:0
?	id在数据库表中为bigint型 在对象中为long型
Top

	回复人：iori_powermax()	2006-03-02 01:06:00	得分:0
?	我也在学习hibernate,不知道说的对不对. 你删除的应该是整个对象,而不是一个id,所以应该为: Info info = (Info)session.load(Info.class,id); session.delete(info); 或者还有一种删除记录的方法: info=(Info)sn.creatQuery("from Info as a where a.ID= '"+delId+"'").uniqueResult(); sn.delete(info); 另外想问一下大家: hibernate的creatSQLQuery()是不是只支持查询?好象增删改都不可以
Top

	回复人：ymfhcn(这痞子真帅)	2006-03-02 08:06:00	得分:0
?	creatSQLQuery()是执行sql语句的，不过稍微有些改动，里面什么SQL语句都可以写  | = | 一般分类 | 仙侠修真 | VBScript | .NET | 面试题 | 存储过程 | Hibernate | JavaScript | J2EE | Struts 自我介绍 我选择，所以我自由！ 切换风格 布局：选择页面布局两栏左侧导航（缺省）两栏右侧导航三栏 配色：选择配色方案纯净蓝灰（缺省）浪漫紫清爽绿海蓝粉红 提示点击带有"..."标记的栏目可以展开/收拢相应的栏目 展开所有 收拢所有 订阅我的Blog 博客日历 « 八月 2006 » 一 二 三 四 五 六 日   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31       文章归档... 八月 2006(1篇) 七月 2006(3篇) 六月 2006(2篇) 五月 2006(5篇) 四月 2006(16篇) 三月 2006(6篇) 最新发表... 关闭窗口的好方法！ 显示格式为：XX月XX日－XX月XX日（前一个为上周六，后一个为本周五） 修改Web.Config文件的函数(vb.net) VBScript得到本周的周末日期函数 给定一个日期，计算此日期是一年中的第几周！ javascript中parseInt的问题 利用javascript得到上周或下周的日期 如何得到前几天的日期 侯捷观点:Java反射机制[转载] 让JSP页面不缓存[设置JSP页面立即过期] 博客统计... 总文章数: 33 总评论数: 16 总引用数: 0 总浏览数: 2744 网站链接... J2EE J2EE&JAVA FAQ 资源 Powered by: Blog Provider: Designed by: =========================================================== Hibernate 的 session.delete(obj =========================================================== 作者: iceling2008(http://iceling2008.itpub.net) 发表于:2006.03.30 16:33 分类: Hibernate 出处：http://iceling2008.itpub.net/post/13270/64328 --------------------------------------------------------------- session.delete(obj)将obj的状态变为transient。两种情况 1）obj是session的cache里边的cache没有的，比如： session.delete(new Employee(4)); 2）obj存在于session的cache中，比如： Employee employee = (Employee)session.load(Employee.class, new Integer(4)); session.delete(employee); 这两种情况都是允许的，hibernate都会发送一条delete语句给数据库。 delete执行之后，如果调用了session.load(), 又可以分为两种情况：1）在session.flush()之前，如： tx.beginTransaction(); 　　　 session.delete(new Employee(4)); session.load(Employee.class, new Integer(4));//发生在session.flush()之前 tx.commit(); 那么hibernate会抛出ObjectDeletedException:The object with that id was deleted: 2）在session.flush()之后，如： tx.beginTransaction(); 　　　 session.delete(new Employee(4)); session.load(Employee.class, new Integer(4)); tx.commit(); tx.beginTransaction(); session.load(Employee.class, new Integer(4));//同一个session中，上面的tx.commit()将session flush了一次。 tx.commit(); 那么这个时候hibernate仅仅会抛出ObjectNotFoundException:No row with the give... 表示找不到该object。如果第二个tx里边采用session.get()也就不会抛出exception了。 delete执行之后，如果调用了session.save(obj): tx.beginTransaction(); Employee employee = (Employee)session.load(Employee.class, new Integer(4)); 　　　 session.delete(employee); System.out.println(employee); session.save(employee); System.out.println(employee); tx.commit(); 这种情况是完全合理的，合法的。 delete将employee从persistent的状态变为transient的状态。 save将employee从transient状态变为persistent的状态。save一个被delete的obj的时候，在save处hibernate强制执行session.flush()，发送delete语句，然后按照常规的save流程来进行。为什么要这么做，还没有完全想明白。 delete执行之后，如果对obj对象属性的修改，tx.commit()时不会进行dirtyChecking。 这个道理比较显然。 - 作者： HairRoot 2005年05月

高级 DAO 编程 学习编译更好的 DAO 的技巧

文档选项 将此页作为电子邮件发送 未显示需要 JavaScript 的文档选项 最新推荐 Java 应用开发源动力 － 下载免费软件，快速启动开发

级别: 初级

Sean C. Sullivan , 软件工程师

2003 年 10 月 15 日

J2EE 开发人员使用数据访问对象(Data Access Object DAO)设计模式，以便将低级别的数据访问逻辑与高级别的业务逻辑分离。实现 DAO 模式涉及比编写数据访问代码更多的内容。在本文中，Java 开发人员 Sean C. Sullivan 讨论了 DAO 编程中三个常常被忽略的方面：事务界定、异常处理和日志记录。

在过去 18 个月中，我参加了一个由有才华的软件工程师组成的小组，构建定制的、基于 Web 的供应链管理应用程序。我们的应用程序访问范围广泛的持久性数据，包括配送状态、供应链衡量(metrics)、库存、货运发票、项目管理数据和用户信息。我们用 JDBC API 连接到我们公司的不同数据库平台上，并在整个应用程序中使用 DAO 设计模式。

图 1 显示了应用程序和数据源之间的关系：

在整个应用程序中使用数据访问对象(DAO)使我们可以将底层数据访问逻辑与业务逻辑分离开来。我们构建了为每一个数据源提供 GRUD (创建、读取、更新、删除)操作的 DAO 类。

在本文中，我将为您介绍构建更好的 DAO 类的 DAO 实现策略和技术。更确切地说，我将讨论日志、异常处理和事务界定。您将学到如何将这三者结合到自己的 DAO 类中。本文假定您熟悉 JDBC API、SQL 和关系数据库编程。

我们将以对 DAO 设计模式和数据访问对象的概述开始。

DAO基础

DAO 模式是标准 J2EE 设计模式之一。开发人员用这种模式将底层数据访问操作与高层业务逻辑分离开。一个典型的 DAO 实现有以下组件：

• 一个 DAO 工厂类
• 一个 DAO 接口
• 一个实现了 DAO 接口的具体类
• 数据传输对象(有时称为值对象)

具体的 DAO 类包含访问特定数据源的数据的逻辑。在下面一节中您将学习设计和实现数据访问对象的技术。有关 DAO 设计模式的更多内容请参阅 参考资料。

回页首

事务界定

关于 DAO 要记住的重要一点是它们是事务性对象。由 DAO 所执行的每一个操作 -- 如创建、更新或者删除数据 -- 都与一个事务相关联。因此， 事务界定的概念就变得特别重要了。

事务界定是定义事务边界的方式。J2EE 规范描述了两种事务界定的模型：编程式(programmatic)和声明式(declarative)。表 1 分析了这两种模型：

表 1. 两种事务界定的模型

我们将侧重于编程式事务界定。

设计考虑

如前所述，DAO 是事务性对象。一个典型的 DAO 执行像创建、更新和删除这样的事务性操作。在设计 DAO 时，首先要问自己以下问题：

• 事务要如何开始？
• 事务应如何结束？
• 哪一个对象将负责开始一个事务？
• 哪一个对象将负责结束一个事务？
• DAO 是否要负责事务的开始和结束？
• 应用程序是否需要通过多个 DAO 访问数据？
• 事务涉及到一个 DAO 还是多个 DAO？
• 一个 DAO 是否调用另一个 DAO 的方法？

了解上述问题的答案将有助于您选择最适合的 DAO 的事务界定策略。在 DAO 中有两种主要的界定事务的策略。一种方式是让 DAO 负责界定事务，另一种将事务界定交给调用这个 DAO 方法的对象处理。如果选择了前一种方式，那么就将事务代码嵌入到 DAO 中。如果选择后一种方式，那么事务界定代码就是在 DAO 类外面。我们将使用简单的代码示例帮助您更好理解每一种方式是如何工作的。

清单 1 显示了一个有两种数据操作的 DAO：创建和更新：

												
														       public void createWarehouseProfile(WHProfile profile);
       public void updateWarehouseStatus(WHIdentifier id, StatusInfo status);

												
										

清单 2 显示了一个简单的事务。事务界定在 DAO 类外面。注意在这个例子中调用者是如何在一个事务中结合多个 DAO 操作的。

												
														      tx.begin();    // start the transaction
      dao.createWarehouseProfile(profile);
      dao.updateWarehouseStatus(id1, status1);
      dao.updateWarehouseStatus(id2, status2);
      tx.commit();   // end the transaction

												
										

这种事务界定策略对于需要在一个事务中访问多个 DAO 的应用程序特别有用。

可以用 JDBC API 或者 Java 事务 API(Java Transaction API JTA)实现事务界定。 JDBC 事务界定比 JTA 事务界定要简单，但是 JTA 提供了更多的灵活性。在下面一节中我将更深入地分析事务界定的机制。

回页首

用 JDBC 进行事务界定

JDBC 事务是用 Connection 对象控制的。JDBC Connection 接口( java.sql.Connection )提供了两种事务模式：自动提交和手工提交。 java.sql.Connection 提供了以下控制事务的方法：

• public void setAutoCommit(boolean)
• public boolean getAutoCommit()
• public void commit()
• public void rollback()

清单 3 显示了如何用 JDBC API 界定一个事务：

												
														      import java.sql.*;
      import javax.sql.*;

      // ...
      DataSource ds = obtainDataSource();
      Connection conn = ds.getConnection();
      conn.setAutoCommit(false);
      // ...
      pstmt = conn.prepareStatement("UPDATE MOVIES ...");
      pstmt.setString(1, "The Great Escape");
      pstmt.executeUpdate();
      // ...
      conn.commit();
      // ...

												
										

使用 JDBC 事务界定时，您可以将多个 SQL 语句结合到一个事务中。JDBC 事务的一个缺点是事务的范围局限于一个数据库连接。一个 JDBC 事务不能跨越多个数据库。在下面，我们将看一下如何用 JTA 进行事务界定。因为 JTA 不像 JDBC 那样有名，所以我们首先做一个简介。

回页首

JTA简介

Java 事务 API(JTA) 及其同门兄弟 Java 事务服务(Java Transaction Service JTS)为 J2EE 平台提供了分布式事务服务。一个 分布式的事务涉及一个事务管理器和一个或者多个资源管理器。一个 资源管理器是任何类型的持久性的数据存储。事务管理器负责协调所有事务参与者之间的通信。事务管理器与资源管理器之间的关系如图 2 所示：

JTA 事务比 JDBC 事务功能更强。JDBC 事务局限为一个数据库连接，而 JTA 事务可以有多个参与者。所有下列 Java 平台组件都可以参与 JTA 事务：

• JDBC 连接
• JDO PersistenceManager 对象
• JMS 队列
• JMS 主题
• 企业 JavaBeans
• 符合 J2EE 连接体系结构(J2EE Connector Architecture)规范的资源适配器

回页首

使用 JTA 的事务界定

要用 JTA 进行事务界定，应用程序要调用 javax.transaction.UserTransaction 接口中的方法。清单 4 显示了对 UserTransaction 对象的典型 JNDI 查询：

												
														      import javax.transaction.*;
      import javax.naming.*;
      // ...
      InitialContext ctx = new InitialContext();
      Object txObj = ctx.lookup("java:comp/UserTransaction");
      UserTransaction utx = (UserTransaction) txObj;


												
										

当应用程序找到了 UserTransaction 对象后，就可以开始事务了，如清单 5 所示：

												
														      utx.begin();
      // ...
      DataSource ds = obtainXADataSource();
      Connection conn = ds.getConnection();
      pstmt = conn.prepareStatement("UPDATE MOVIES ...");
      pstmt.setString(1, "Spinal Tap");
      pstmt.executeUpdate();
      // ...
      utx.commit();
      // ...


												
										

当应用程序调用 commit() 时，事务管理器用一个两阶段的提交协议结束事务。

回页首

控制事务的 JTA 方法

javax.transaction.UserTransaction 接口提供了以下事务控制方法：

• public void begin()
• public void commit()
• public void rollback()
• public int getStatus()
• public void setRollbackOnly()
• public void setTransactionTimeout(int)

应用程序调用 begin() 开始事务。应用程序调用 commit() 或者 rollback() 结束事务。参阅 参考资料以了解更多关于用 JTA 进行事务管理的内容。

回页首

使用 JTA 和 JDBC

开发人员通常在 DAO 类中用 JDBC 进行底层数据操作。如果计划用 JTA 界定事务，那么就需要有一个实现 javax.sql.XADataSource 、 javax.sql.XAConnection 和 javax.sql.XAResource 接口的 JDBC 驱动程序。一个实现了这些接口的驱动程序将可以参与 JTA 事务。一个 XADataSource 对象就是一个 XAConnection 对象的工厂。 XAConnection s 是参与 JTA 事务的 JDBC 连接。

您将需要用应用服务器的管理工具设置 XADataSource 。从应用服务器和 JDBC 驱动程序的文档中可以了解到相关的指导。

J2EE 应用程序用 JNDI 查询数据源。一旦应用程序找到了数据源对象，它就调用 javax.sql.DataSource.getConnection() 以获得到数据库的连接。

XA 连接与非 XA 连接不同。一定要记住 XA 连接参与了 JTA 事务。这意味着 XA 连接不支持 JDBC 的自动提交功能。同时，应用程序一定不要对 XA 连接调用 java.sql.Connection.commit() 或者 java.sql.Connection.rollback() 。相反，应用程序应该使用 UserTransaction.begin()、UserTransaction.commit() 和 serTransaction.rollback() 。

回页首

选择最好的方式

我们讨论了如何用 JDBC 和 JTA 界定事务。每一种方式都有其优点，您需要决定哪一种最适合于您的应用程序。

在最近的许多项目中，我们小组是用 JDBC API 进事务界定来构建 DAO 类的。这些 DAO 类可以总结如下：

• 事务界定代码嵌入在 DAO 类中。
• DAO 类使用 JDBC API 进行事务界定。
• 调用者不能界定事务。
• 事务范围局限于单个 JDBC 连接。

JDBC 事务并不总是适合复杂的企业应用程序。如果您的事务要跨越多个 DAO 或者多个数据库，那么下列实现策略也许更合适：

• 事务用 JTA 界定。
• 事务界定代码从 DAO 中分离出来。
• 调用者负责界定事务。
• DAO 加入一个全局事务。

JDBC 方式由于其简单性而具有吸引力，JTA　方式提供了更大的灵活性。您所选择的实现将取决于应用程序的特定需求。

回页首

日志记录和 DAO

一个良好实现的 DAO 类将使用日志记录来捕捉有关其运行时行为的细节。您可以选择记录异常、配置信息、连接状态、JDBC 驱动程序元数据、或者查询参数。日志对于开发的所有阶段都很有用。我经常在开发时、测试时和生产中分析应用程序日志。

在本节，我将展示一个显示如何将 Jakarta Commons Logging 加入到 DAO 中的代码示例。在这之前，让我们回顾一下一些基本知识。

选择日志库

许多开发人员使用一种原始格式进行日志记录： System.out.println 和 System.err.println 。 Println 语句速度快且使用方便，但是它们没有提供全功能的日志记录系统所具有的功能。表 2 列出了 Java 平台的日志库：

表 2. Java 平台的日志库

Jakarta Commons Logging 可以与 java.util.logging 或者 Jakarta Log4j 一同使用。Commons Logging 是一个日志抽象层，它隔离了应用程序与底层日志实现。使用 Commons Logging，您可以通过改变配置文件更换底层日志实现。Commons Logging 在 Jakarta Struts 1.1 和 Jakarta HttpClient 2.0 中使用。

一个日志记录示例

清单 7 显示了如何在 DAO 类中使用 Jakarta Commons Logging：

												
														import org.apache.commons.logging.*;

class DocumentDAOImpl implements DocumentDAO
{
      static private final Log log = LogFactory.getLog(DocumentDAOImpl.class);

      public void deleteDocument(String id)
      {
          // ...
          log.debug("deleting document: " + id);
          // ...
          try
          {
              // ... data operations ...
          }
          catch (SomeException ex)
          {
              log.error("Unable to delete document", ex);
              // ... handle the exception ...
	}
      }
}

												
										

日志记录是所有任务关键型应用程序的重要部分。如果在 DAO 中遇到故障，那么日志通常可以提供判断出错位置的最好信息。将日志加入到 DAO 可以保证您有机会进行调试和故障排除。

回页首

DAO 中的异常处理

我们讨论过了事务界定和日志，现在对于如何在数据访问对象上应用它们有了更深入的理解。我们的第三个和最后一个讨论议题是异常处理。遵从几个简单的异常处理指导可以使您的 DAO 更容易使用、更健壮及更易于维护。

在实现 DAO 模式时，考虑以下问题：

• DAO 的公共接口中的方法是否抛出检查过的异常？
• 如果是的话，抛出何种检查过的异常？
• 在 DAO 实现类中如何处理异常？

在使用 DAO 模式的过程中，我们的小组开发了一些处理异常的原则。遵从这些原则可以极大地改进您的 DAO：

• DAO 方法应该抛出有意义的异常。
• DAO 方法不应该抛出 java.lang.Exception 。 java.lang.Exception 太一般化了。它不传递关于底层问题的任何信息。
  
• DAO 方法不应该抛出 java.sql.SQLException 。SQLException 是一个低级别的 JDBC 异常。一个 DAO 应该力争封装 JDBC 而不是将 JDBC 公开给应用程序的其余部分。
  
• 只有在可以合理地预期调用者可以处理异常时，DAO 接口中的方法才应该抛出检查过的异常。如果调用者不能以有意义的方式处理这个异常，那么考虑抛出一个未检查的(运行时)异常。
• 如果数据访问代码捕获了一个异常，不要忽略它。忽略捕获的异常的 DAO 是很难进行故障诊断的。
• 使用链接的异常将低级别的异常转化为高级别的异常。
• 考虑定义标准 DAO 异常类。Spring Framework (参阅 参考资料)提供了很好的一套预定义的 DAO 异常类。

有关异常和异常处理技术的更多信息参阅 参考资料。

回页首

实现实例： MovieDAO

MovieDAO 是一个展示本文中讨论的所有技术的 DAO：事务界定、日志和异常处理。您可以在 参考资料一节中找到 MovieDAO 源代码。代码分为三个包：

• daoexamples.exception
• daoexamples.movie
• daoexamples.moviedemo

DAO 模式的这个实现包含下面列出的类和接口：

• daoexamples.movie.MovieDAOFactory
• daoexamples.movie.MovieDAO
• daoexamples.movie.MovieDAOImpl
• daoexamples.movie.MovieDAOImplJTA
• daoexamples.movie.Movie
• daoexamples.movie.MovieImpl
• daoexamples.movie.MovieNotFoundException
• daoexamples.movie.MovieUtil

MovieDAO 接口定义了 DAO 的数据操作。这个接口有五个方法，如下所示：

• public Movie findMovieById(String id)
• public java.util.Collection findMoviesByYear(String year)
• public void deleteMovie(String id)
• public Movie createMovie(String rating, String year, String, title)
• public void updateMovie(String id, String rating, String year, String title)

daoexamples.movie 包包含 MovieDAO 接口的两个实现。每一个实现使用一种不同的方式进行事务界定，如表 3 所示：

表 3. MovieDAO 实现

MovieDAO 演示应用程序

这个演示应用程序是一个名为 daoexamples.moviedemo.DemoServlet 的 servlet 类。 DemoServlet 使用这两个 Movie DAO 查询和更新表中的电影数据。

这个 servlet 展示了如何将支持 JTA 的 MovieDAO 和 Java 消息服务(Java Message Service)结合到一个事务中，如清单 8 所示。

												
															UserTransaction utx = MovieUtil.getUserTransaction();
	utx.begin();
	batman = dao.createMovie("R",
			"2008",
			"Batman Reloaded");
	publisher = new MessagePublisher();
	publisher.publishTextMessage("I'll be back");
	dao.updateMovie(topgun.getId(),
			"PG-13",
			topgun.getReleaseYear(),
			topgun.getTitle());
	dao.deleteMovie(legallyblonde.getId());
	utx.commit();

												
										

 当前位置: 首页 >> 数据库 >> Oracle >> 我的权限控制(JBX + struts + hibernate + ORACLE)
 
我的权限控制(JBX + struts + hibernate + ORACLE) 

--------------------------------------------------------------------------------
 
作者：:     来源：     发表时间：2006-06-08     浏览次数：18    字号：大  中  小
　　
通过过滤器判断用户权限.
第一步:建立UserPermissionFilter类.

import javax.servlet.*;
import javax.servlet.http.*;
import java.io.*;
import java.util.*;

import test.system.SysUserApi;
import test.vo.SysUserVO;
import test.system.dao.SysUserDao;
import test.Const;

public class UserPermissionFilter extends HttpServlet implements Filter {

  protected FilterConfig filterConfig = null;

  public void destroy() {
    this.filterConfig = null;
  }

  public void doFilter(
      ServletRequest request,
      ServletResponse response,
      FilterChain filterChain) throws IOException, ServletException {
    try {
      HttpServletRequest req = (HttpServletRequest) request;
      SysUserVO userSession = new SysUserVO();
      userSession = (SysUserVO)req.getSession().getAttribute(Const.SESSION_USER);
      if (userSession == null) {
        HttpServletResponse rep = (HttpServletResponse) response;

        rep.sendRedirect("/admin/login.jsp");
             }else{
        filterChain.doFilter(request, response);
      }
    }
    catch (Exception e) {}
  }
  public void init(FilterConfig filterConfig) throws ServletException {
    this.filterConfig = filterConfig;
  }
  public FilterConfig getFilterConfig() {
    return filterConfig;
  }

  public void setFilterConfig(FilterConfig filterConfig) {
    this.filterConfig = filterConfig;
  }

}

第二步:配置WEB.xml文件
设置过滤器:
  <filter>
    <filter-name>userpermission</filter-name>
    <filter-class>sports.tools.UserPermissionFilter</filter-class>
  </filter>
设置过滤器映射,因为过滤器不能过滤全部的程序,所以可以用列表的形式来增加需要过滤的文件.如下.一个过滤器可以过滤多个映射文件.
  <filter-mapping>
    <filter-name>userpermission</filter-name>
    <url-pattern>/admin/index.jsp</url-pattern>
  </filter-mapping>

  <filter-mapping>
    <filter-name>userpermission</filter-name>
    <url-pattern>/admin/edit/*</url-pattern>
  </filter-mapping>
 
 
 
======================================
http://www.itwenzhai.com/data/2006/0608/article_22958.htm
=========================================
http://www.itwenzhai.com/data/2006/0626/article_25178.htm
=========================================

  不重复DAO
===============

由于 Java™ 5 泛型的采用，有关泛型类型安全 Data Access Object (DAO) 实现的想法变得切实可行。在本文中，系统架构师 Per Mellqvist 展示了基于 Hibernate 的泛型 DAO 实现类。然后展示如何使用 Spring AOP introductions 将类型安全接口添加到类中以便于查询执行。
对于大多数开发人员，为系统中的每个 DAO 编写几乎相同的代码到目前为止已经成为一种习惯。虽然所有人都将这种重复标识为 “代码味道”，但我们大多数都已经学会忍受它。其实有解决方案。可以使用许多 ORM 工具来避免代码重复。例如，使用 Hibernate，您可以简单地为所有的持久域对象直接使用会话操作。这种方法的缺点是损失了类型安全。

为什么您要为数据访问代码提供类型安全接口？我会争辩说，当它与现代 IDE 工具一起使用时，会减少编程错误并提高生产率。首先，类型安全接口清楚地指明哪些域对象具有可用的持久存储。其次，它消除了易出错的类型强制转换的需要（这是一个在查询操作中比在 CRUD 中更常见的问题）。最后，它有效利用了今天大多数 IDE 具备的自动完成特性。使用自动完成是记住什么查询可用于特定域类的快捷方法。

在本文中，我将为您展示如何避免再三地重复 DAO 代码，而仍保留类型安全接口的优点。事实上，您需要为每个新 DAO 编写的只是 Hibernate 映射文件、无格式旧 Java 接口以及 Spring 配置文件中的 10 行。

DAO 实现

DAO 模式对任何企业 Java 开发人员来说都应该很熟悉。但是模式的实现各不相同，所以我们来澄清一下本文提供的 DAO 实现背后的假设：

系统中的所有数据库访问都通过 DAO 进行以实现封装。
每个 DAO 实例负责一个主要域对象或实体。如果域对象具有独立生命周期，它应具有自己的 DAO。
DAO 负责域对象的创建、读取（按主键）、更新和删除（creations, reads, updates, and deletions，CRUD）。
DAO 可允许基于除主键之外的标准进行查询。我将之称为查找器方法 或查找器。查找器的返回值通常是 DAO 负责的域对象集合。
DAO 不负责处理事务、会话或连接。这些不由 DAO 处理是为了实现灵活性。
泛型 DAO 接口

泛型 DAO 的基础是其 CRUD 操作。下面的接口定义泛型 DAO 的方法：

清单 1. 泛型 DAO 接口
public interface GenericDao <T, PK extends Serializable> {

    /** Persist the newInstance object into database */
    PK create(T newInstance);

    /** Retrieve an object that was previously persisted to the database using
     *   the indicated id as primary key
     */
    T read(PK id);

    /** Save changes made to a persistent object.  */
    void update(T transientObject);

    /** Remove an object from persistent storage in the database */
    void delete(T persistentObject);
}

实现接口

用 Hibernate 实现清单 1 中的接口十分简单，如清单 2 所示。它只需调用底层 Hibernate 方法和添加强制类型转换。Spring 负责会话和事务管理。（当然，我假设这些函数已做了适当的设置，但该主题在 Hibernate 和 Springt 手册中有详细介绍。）

清单 2. 第一个泛型 DAO 实现
public class GenericDaoHibernateImpl <T, PK extends Serializable>
    implements GenericDao<T, PK>, FinderExecutor {
    private Class<T> type;

    public GenericDaoHibernateImpl(Class<T> type) {
        this.type = type;
    }

    public PK create(T o) {
        return (PK) getSession().save(o);
    }

    public T read(PK id) {
        return (T) getSession().get(type, id);
    }

    public void update(T o) {
        getSession().update(o);
    }

    public void delete(T o) {
        getSession().delete(o);
    }

    // Not showing implementations of getSession() and setSessionFactory()
            }
 

Spring 配置

最后，在 Spring 配置中，我创建了 GenericDaoHibernateImpl 的一个实例。必须告诉 GenericDaoHibernateImpl 的构造函数 DAO 实例将负责哪个域类。只有这样，Hibernate 才能在运行时知道由 DAO 管理的对象类型。在清单 3 中，我将域类 Person 从示例应用程序传递给构造函数，并将先前配置的 Hibernate 会话工厂设置为已实例化的 DAO 的参数：

清单 3. 配置 DAO
<bean id="personDao" class="genericdao.impl.GenericDaoHibernateImpl">
        <constructor-arg>
            <value>genericdaotest.domain.Person</value>
        </constructor-arg>
        <property name="sessionFactory">
            <ref bean="sessionFactory"/>
        </property>
</bean>
        
2。
我还没有完成，但我所完成的确实已经可以使用了。在清单 4 中，可以看到原封不动使用该泛型 DAO 的示例：

清单 4. 使用 DAO
public void someMethodCreatingAPerson() {
    ...
    GenericDao dao = (GenericDao)
     beanFactory.getBean("personDao"); // This should normally be injected

    Person p = new Person("Per", 90);
    dao.create(p);
}
        

现在，我有一个能够进行类型安全 CRUD 操作的泛型 DAO。让子类 GenericDaoHibernateImpl 为每个域对象添加查询能力将非常合理。因为本文的目的在于展示如何不为每个查询编写显式的 Java 代码来实现查询，但是，我将使用其他两个工具将查询引入 DAO，也就是 Spring AOP 和 Hibernate 命名的查询。

Spring AOP introductions

可以使用 Spring AOP 中的 introductions 将功能添加到现有对象，方法是将功能包装在代理中，定义应实现的接口，并将所有先前未支持的方法指派到单个处理程序。在我的 DAO 实现中，我使用 introductions 将许多查找器方法添加到现有泛型 DAO 类中。因为查找器方法是特定于每个域对象的，因此将其应用于泛型 DAO 的类型化接口。

Spring 配置如清单 5 所示：

清单 5. FinderIntroductionAdvisor 的 Spring 配置
<bean id="finderIntroductionAdvisor" class="genericdao.impl.FinderIntroductionAdvisor"/>

<bean id="abstractDaoTarget"
        class="genericdao.impl.GenericDaoHibernateImpl" abstract="true">
        <property name="sessionFactory">
            <ref bean="sessionFactory"/>
        </property>
</bean>

<bean id="abstractDao"
        class="org.springframework.aop.framework.ProxyFactoryBean" abstract="true">
        <property name="interceptorNames">
            <list>
                <value>finderIntroductionAdvisor</value>
            </list>
        </property>
</bean>
        

在清单 5 的配置文件中，我定义了三个 Spring bean。第一个 bean 是 FinderIntroductionAdvisor，它处理引入到 DAO 的所有方法，这些方法在 GenericDaoHibernateImpl 类中不可用。我稍后将详细介绍 Advisor bean。

第二个 bean 是 “抽象的”。在 Spring 中，这意味着该 bean 可在其他 bean 定义中被重用，但不被实例化。除了抽象特性之外，该 bean 定义只指出我想要 GenericDaoHibernateImpl 的实例以及该实例需要对 SessionFactory 的引用。注意，GenericDaoHibernateImpl 类仅定义一个构造函数，该构造函数接受域类作为其参数。因为该 bean 定义是抽象的，所以我将来可以无数次地重用该定义，并将构造函数参数设置为合适的域类。

最后，第三个也是最有趣的 bean 将 GenericDaoHibernateImpl 的 vanilla 实例包装在代理中，赋予其执行查找器方法的能力。该 bean 定义也是抽象的，不指定希望引入到 vanilla DAO 的接口。该接口对于每个具体的实例是不同的。注意，清单 5 显示的整个配置仅定义一次。

3。

扩展 GenericDAO

当然，每个 DAO 的接口都基于 GenericDao 接口。我只需使该接口适应特定的域类并扩展该接口以包括查找器方法。在清单 6 中，可以看到为特定目的扩展的 GenericDao 接口示例：

清单 6. PersonDao 接口
public interface PersonDao extends GenericDao<Person, Long> {
    List<Person> findByName(String name);
}

很明显，清单 6 中定义的方法旨在按名称查找 Person。必需的 Java 实现代码全部是泛型代码，在添加更多 DAO 时不需要任何更新。

配置 PersonDao

因为 Spring 配置依赖于先前定义的 “抽象” bean，因此它变得相当简洁。我需要指出 DAO 负责哪个域类，并且需要告诉 Springs 该 DAO 应实现哪个接口（一些方法是直接使用，一些方法则是通过使用 introductions 来使用）。清单 7 展示了 PersonDAO 的 Spring 配置文件：

清单 7. PersonDao 的 Spring 配置
<bean id="personDao" parent="abstractDao">
    <property name="proxyInterfaces">
        <value>genericdaotest.dao.PersonDao</value>
    </property>
    <property name="target">
        <bean parent="abstractDaoTarget">
            <constructor-arg>
                <value>genericdaotest.domain.Person</value>
            </constructor-arg>
        </bean>
    </property>
</bean>
        

在清单 8 中，可以看到使用了这个更新后的 DAO 版本：

清单 8. 使用类型安全接口
public void someMethodCreatingAPerson() {
    ...
    PersonDao dao = (PersonDao)
     beanFactory.getBean("personDao"); // This should normally be injected

    Person p = new Person("Per", 90);
    dao.create(p);

    List<Person> result = dao.findByName("Per"); // Runtime exception
}
        

虽然清单 8 中的代码是使用类型安全 PersonDao 接口的正确方法，但 DAO 的实现并不完整。调用 findByName() 会导致运行时异常。问题在于我还没有实现调用 findByName() 所必需的查询。剩下要做的就是指定查询。为更正该问题，我使用了 Hibernate 命名查询。

Hibernate 命名查询

使用 Hibernate，可以在 Hibernate 映射文件 (hbm.xml) 中定义 HQL 查询并为其命名。稍后可以通过简单地引用给定名称来在 Java 代码中使用该查询。该方法的优点之一是能够在部署时优化查询，而无需更改代码。您一会将会看到，另一个优点是无需编写任何新 Java 实现代码，就可以实现 “完整的” DAO。清单 9 是带有命名查询的映射文件的示例：

清单 9. 带有命名查询的映射文件
 <hibernate-mapping package="genericdaotest.domain">
     <class name="Person">
         <id name="id">
             <generator class="native"/>
         </id>
         <property name="name" />
         <property name="weight" />
     </class>

     <query name="Person.findByName">
         <![CDATA[select p from Person p where p.name = ? ]]>
     </query>
 </hibernate-mapping>
        

清单 9 定义了域类 Person 的 Hibernate 映射，该域类具有两个属性：name 和 weight。Person 是具有上述属性的简单 POJO。该文件还包含一个在数据库中查找 Person 所有实例的查询，其中 “name” 等于提供的参数。Hibernate 不为命名查询提供任何真正的名称空间功能。出于讨论目的，我为所有查询名称都加了域类的短（非限定）名称作为前缀。在现实世界中，使用包括包名称的完全类名可能是更好的主意。

逐步概述

您已经看到了为任何域对象创建和配置新 DAO 所必需的全部步骤。三个简单的步骤是：

定义一个接口，它扩展 GenericDao 并包含所需的任何查找器方法。
将每个查找器的命名查询添加到域对象的 hbm.xml 映射文件。
为 DAO 添加 10 行 Spring 配置文件。
查看执行查找器方法的代码（只编写了一次！）来结束我的讨论。

4。

可重用的 DAO 类

使用的 Spring advisor 和 interceptor 很简单，事实上它们的工作是向后引用 GenericDaoHibernateImplClass。方法名以 “find” 打头的所有调用都传递给 DAO 和单个方法 executeFinder()。

清单 10. FinderIntroductionAdvisor 的实现
public class FinderIntroductionAdvisor extends DefaultIntroductionAdvisor {
    public FinderIntroductionAdvisor() {
        super(new FinderIntroductionInterceptor());
    }
}

public class FinderIntroductionInterceptor implements IntroductionInterceptor {

    public Object invoke(MethodInvocation methodInvocation) throws Throwable {

        FinderExecutor genericDao = (FinderExecutor) methodInvocation.getThis();

        String methodName = methodInvocation.getMethod().getName();
        if (methodName.startsWith("find")) {
            Object[] arguments = methodInvocation.getArguments();
            return genericDao.executeFinder(methodInvocation.getMethod(), arguments);
        } else {
            return methodInvocation.proceed();
        }
    }

    public boolean implementsInterface(Class intf) {
        return intf.isInterface() && FinderExecutor.class.isAssignableFrom(intf);
    }
}
 

executeFinder() 方法

清单 10 的实现中惟一缺少的是 executeFinder() 实现。该代码查看调用的类和方法的名称，并使用配置上的约定将其与 Hibernate 查询的名称相匹配。还可以使用 FinderNamingStrategy 来支持其他命名查询的方法。默认实现查找叫做 “ClassName.methodName” 的查询，其中 ClassName 是不带包的短名称。清单 11 完成了泛型类型安全 DAO 实现：

清单 11. executeFinder() 的实现
public List<T> executeFinder(Method method, final Object[] queryArgs) {
     final String queryName = queryNameFromMethod(method);
     final Query namedQuery = getSession().getNamedQuery(queryName);
     String[] namedParameters = namedQuery.getNamedParameters();
     for(int i = 0; i < queryArgs.length; i++) {
             Object arg = queryArgs[i];
             Type argType =  namedQuery.setParameter(i, arg);
      }
      return (List<T>) namedQuery.list();
 }

 public String queryNameFromMethod(Method finderMethod) {
     return type.getSimpleName() + "." + finderMethod.getName();
 }
 

结束语

在 Java 5 之前，该语言不支持编写既类型安全又 泛型的代码，您必须只能选择其中之一。在本文中，您已经看到一个结合使用 Java 5 泛型与 Spring 和 Hibernate（以及 AOP）等工具来提高生产率的示例。泛型类型安全 DAO 类相当容易编写 —— 您只需要单个接口、一些命名查询和为 Spring 配置添加的 10 行代码 —— 而且可以极大地减少错误并节省时间。

几乎本文的所有代码都是可重用的。尽管您的 DAO 类可能包含此处没有实现的查询和操作类型（比如，批操作），但使用我所展示的技术，您至少应该能够实现其中的一部分。参阅 参考资料 了解其他泛型类型安全 DAO 类实现。

致谢

自 Java 语言中出现泛型以来，单个泛型类型安全 DAO 的概念已经成为主题。我曾在 JavaOne 2004 中与 Don Smith 简要讨论了泛型 DAO 的灵活性。本文使用的 DAO 实现类旨在作为示例实现，实际上还存在其他实现。例如，Christian Bauer 已经发布了带有 CRUD 操作和标准搜索的实现，Eric Burke 也在该领域做出了工作。我确信将会有更多的实现出现。我要额外感谢 Christian，他目睹了我编写泛型类型安全 DAO 的第一次尝试并提出改进建议。最后，我要感谢 Ramnivas Laddad 的无价帮助，他审阅了本文。