BlogJava-hk2000c技术专栏-随笔分类-CMS项目开发

为BO加入SecurityObject控制

hk2000c — Wed, 23 Jan 2008 16:04:00 GMT

这样可以做到对所有对象的安全性控制。
可以扩展到一切的业务对象。
包括基础方法，操作。
甚至安全对象本身
有点神学的味道。

可能是因为采用其他被创造者不知道的机制，所以被创造者无法理解和知晓。

hk2000c 2008-01-24 00:04 发表评论

关于要求hibernate事务报session设置为auto标志异常问题

hk2000c — Fri, 30 Nov 2007 06:01:00 GMT

通常是封装在某一级的接口或者类没有事务声明所致





申明一下就可以了

hk2000c 2007-11-30 14:01 发表评论

BO设计定稿

hk2000c — Thu, 15 Nov 2007 11:26:00 GMT

BO设计定稿

等过些时候重新审视自己的设计再说

hk2000c 2007-11-15 19:26 发表评论

一般性data bind 流程

hk2000c — Sun, 11 Nov 2007 21:22:00 GMT

org.springframework.web.bind.ServletRequestDataBinder@27ca12

DataBinder: applyPropertyValues(MutablePropertyValues mpvs)

org.springframework.beans.BeanWrapperImpl: wrapping object [com.unitedbiz.model.User@996f0e]
AbstractPropertyAccessor::setPropertyValues(PropertyValues pvs, boolean ignoreUnknown, boolean ignoreInvalid)

org.springframework.beans.BeanWrapperImpl: wrapping object [com.unitedbiz.model.User@996f0e]::setPropertyValue(PropertyValue pv)

hk2000c 2007-11-12 05:22 发表评论

filter 位置不能颠倒

hk2000c — Thu, 08 Nov 2007 11:29:00 GMT

filter 位置不能颠倒

一般位置顺序为

encoding

hibernate

localeFilter

securityFilter

sitemesh

hk2000c 2007-11-08 19:29 发表评论

在validation.xml中进行相关的验证配置

hk2000c — Wed, 07 Nov 2007 17:10:00 GMT

．在validation.xml中进行相关的验证配置如：

所注意的问题：1、如在arg0中如果不设置验证器，那么就被所有的验证器通用
2、如中的arg1要与错误信息中所对应的该验证器的参数一至（errors.maxlength={0} can not be greater than {1} characters.）
如果（errors.maxlength={0} can not be greater than {2} characters.）的话，那么就必须将2改为1

7.jsp中的前台验证：

//对应formBean的名字

hk2000c 2007-11-08 01:10 发表评论

OSCache 避免死锁

hk2000c — Wed, 07 Nov 2007 05:09:00 GMT

OSCache 避免死锁

在正常更新 cache 后，不要调用

cache.cancelUpdate(url);

方法

否则会引起系统死锁

hk2000c 2007-11-07 13:09 发表评论

详解spring事务属性

hk2000c — Thu, 01 Nov 2007 08:13:00 GMT

Spring声明式事务让我们从复杂的事务处理中得到解脱。使得我们再也无需要去处理获得连接、关闭连接、事务提交和回滚等这些操作。再也无需要我们在与事务相关的方法中处理大量的try…catch…finally代码。
我们在使用Spring声明式事务时，有一个非常重要的概念就是事务属性。事务属性通常由事务的传播行为，事务的隔离级别，事务的超时值和事务只读标志组成。我们在进行事务划分时，需要进行事务定义，也就是配置事务的属性。
Spring在TransactionDefinition接口中定义这些属性,以供PlatfromTransactionManager使用, PlatfromTransactionManager是spring事务管理的核心接口。

代码

TransactionDefinition
public interface TransactionDefinition {
int getPropagationBehavior();
int getIsolationLevel();
int getTimeout();
boolean isReadOnly();
}

getTimeout()方法，它返回事务必须在多少秒内完成。
isReadOnly(),事务是否只读，事务管理器能够根据这个返回值进行优化，确保事务是只读的。
getIsolationLevel()方法返回事务的隔离级别，事务管理器根据它来控制另外一个事务可以看到本事务内的哪些数据。

在TransactionDefinition接口中定义了五个不同的事务隔离级别
ISOLATION_DEFAULT 这是一个PlatfromTransactionManager默认的隔离级别，使用数据库默认的事务隔离级别.另外四个与JDBC的隔离级别相对应
ISOLATION_READ_UNCOMMITTED 这是事务最低的隔离级别，它充许别外一个事务可以看到这个事务未提交的数据。这种隔离级别会产生脏读，不可重复读和幻像读。
例如:
Mary的原工资为1000,财务人员将Mary的工资改为了8000，但未提交事务

代码

Connection con1 = getConnection();
con.setAutoCommit(false);
update employee set salary = 8000 where empId ="Mary";

与此同时，Mary正在读取自己的工资

代码

Connection con2 = getConnection();
select salary from employee where empId ="Mary";
con2.commit();

Mary发现自己的工资变为了8000，欢天喜地！
而财务发现操作有误，而回滚了事务,Mary的工资又变为了1000

代码

//con1
con1.rollback();

像这样,Mary记取的工资数8000是一个脏数据。

ISOLATION_READ_COMMITTED 保证一个事务修改的数据提交后才能被另外一个事务读取。另外一个事务不能读取该事务未提交的数据。这种事务隔离级别可以避免脏读出现，但是可能会出现不可重复读和幻像读。

ISOLATION_REPEATABLE_READ 这种事务隔离级别可以防止脏读，不可重复读。但是可能出现幻像读。它除了保证一个事务不能读取另一个事务未提交的数据外，还保证了避免下面的情况产生(不可重复读)。

在事务1中，Mary 读取了自己的工资为1000,操作并没有完成

代码

con1 = getConnection();
select salary from employee empId ="Mary";

在事务2中，这时财务人员修改了Mary的工资为2000,并提交了事务.

代码

con2 = getConnection();
update employee set salary = 2000;
con2.commit();

在事务1中，Mary 再次读取自己的工资时，工资变为了2000

代码

//con1
select salary from employee empId ="Mary";

在一个事务中前后两次读取的结果并不致，导致了不可重复读。
使用ISOLATION_REPEATABLE_READ可以避免这种情况发生。

ISOLATION_SERIALIZABLE 这是花费最高代价但是最可靠的事务隔离级别。事务被处理为顺序执行。除了防止脏读，不可重复读外，还避免了幻像读。

目前工资为1000的员工有10人。
事务1,读取所有工资为1000的员工。

代码

con1 = getConnection();
Select * from employee where salary =1000;

共读取10条记录

这时另一个事务向employee表插入了一条员工记录，工资也为1000

代码

con2 = getConnection();
Insert into employee(empId,salary) values("Lili",1000);
con2.commit();

事务1再次读取所有工资为1000的员工

代码

//con1
select * from employee where salary =1000;

共读取到了11条记录，这就产生了幻像读。
ISOLATION_SERIALIZABLE能避免这样的情况发生。但是这样也耗费了最大的资源。

getPropagationBehavior()返回事务的传播行为，由是否有一个活动的事务来决定一个事务调用。

在TransactionDefinition接口中定义了七个事务传播行为。

PROPAGATION_REQUIRED 如果存在一个事务，则支持当前事务。如果没有事务则开启一个新的事务。

代码

//事务属性 PROPAGATION_REQUIRED
methodA{
……
methodB();
……
}
//事务属性 PROPAGATION_REQUIRED
methodB{
……
}

使用spring声明式事务，spring使用AOP来支持声明式事务，会根据事务属性，自动在方法调用之前决定是否开启一个事务，并在方法执行之后决定事务提交或回滚事务。

单独调用methodB方法

代码

main{
metodB();
}

相当于

代码

Main{
Connection con=null;
rry{
con = getConnection();
con.setAutoCommit(false);
//方法调用
methodB();
//提交事务
con.commit();
}
Catch(RuntimeException ex){
//回滚事务
con.rollback();
}
finally{
//释放资源
closeCon();
}
}

Spring保证在methodB方法中所有的调用都获得到一个相同的连接。在调用methodB时，没有一个存在的事务，所以获得一个新的连接，开启了一个新的事务。

单独调用MethodA时，在MethodA内又会调用MethodB.

执行效果相当于

代码

main{
Connection con = null;
try{
con = getConnection();
methodA();
con.commit();
}
cathc(RuntimeException ex){
con.rollback();
}
finally{
closeCon();
}
}

调用MethodA时，环境中没有事务，所以开启一个新的事务.
当在MethodA中调用MethodB时，环境中已经有了一个事务，所以methodB就加入当前事务。

PROPAGATION_SUPPORTS 如果存在一个事务，支持当前事务。如果没有事务，则非事务的执行。但是对于事务同步的事务管理器，PROPAGATION_SUPPORTS与不使用事务有少许不同。

代码

//事务属性 PROPAGATION_REQUIRED
methodA(){
methodB();
}
//事务属性 PROPAGATION_SUPPORTS
methodB(){
……
}

单纯的调用methodB时，methodB方法是非事务的执行的。
当调用methdA时,methodB则加入了methodA的事务中,事务地执行。

PROPAGATION_MANDATORY 如果已经存在一个事务，支持当前事务。如果没有一个活动的事务，则抛出异常。

代码

//事务属性 PROPAGATION_REQUIRED
methodA(){
methodB();
}
//事务属性 PROPAGATION_MANDATORY
methodB(){
……
}

当单独调用methodB时，因为当前没有一个活动的事务，则会抛出异常
throw new IllegalTransactionStateException("Transaction propagation 'mandatory' but no existing transaction found");

当调用methodA时，methodB则加入到methodA的事务中，事务地执行。

PROPAGATION_REQUIRES_NEW 总是开启一个新的事务。如果一个事务已经存在，则将这个存在的事务挂起。

代码

//事务属性 PROPAGATION_REQUIRED
methodA(){
doSomeThingA();
methodB();
doSomeThingB();
}
//事务属性 PROPAGATION_REQUIRES_NEW
methodB(){
……
}

当单独调用methodB时，相当于把methodb声明为REQUIRED。开启一个新的事务，事务地执行。

当调用methodA时

代码

main(){
methodA();
}

情况有些大不一样.相当于下面的效果。

代码

main(){
TransactionManager tm = null;
try{
//获得一个JTA事务管理器
tm = getTransactionManager();
tm.begin();//开启一个新的事务
Transaction ts1 = tm.getTransaction();
doSomeThing();
tm.suspend();//挂起当前事务
try{
tm.begin();//重新开启第二个事务
Transaction ts2 = tm.getTransaction();
methodB();
ts2.commit();//提交第二个事务
}
Catch(RunTimeException ex){
ts2.rollback();//回滚第二个事务
}
finally{
//释放资源
}
//methodB执行完后，复恢第一个事务
tm.resume(ts1);
doSomeThingB();
ts1.commit();//提交第一个事务
}
catch(RunTimeException ex){
ts1.rollback();//回滚第一个事务
}
finally{
//释放资源
}
}

在这里，我把ts1称为外层事务，ts2称为内层事务。从上面的代码可以看出，ts2与ts1是两个独立的事务，互不相干。Ts2是否成功并不依赖于ts1。如果methodA方法在调用methodB方法后的doSomeThingB方法失败了，而methodB方法所做的结果依然被提交。而除了methodB之外的其它代码导致的结果却被回滚了。
使用PROPAGATION_REQUIRES_NEW,需要使用JtaTransactionManager作为事务管理器。

PROPAGATION_NOT_SUPPORTED 总是非事务地执行，并挂起任何存在的事务。

代码

//事务属性 PROPAGATION_REQUIRED
methodA(){
doSomeThingA();
methodB();
doSomeThingB();
}
//事务属性 PROPAGATION_NOT_SUPPORTED
methodB(){
……
}

当单独调用methodB时，不启用任何事务机制，非事务地执行。
当调用methodA时，相当于下面的效果

代码

main(){
TransactionManager tm = null;
try{
//获得一个JTA事务管理器
tm = getTransactionManager();
tm.begin();//开启一个新的事务
Transaction ts1 = tm.getTransaction();
doSomeThing();
tm.suspend();//挂起当前事务
methodB();
//methodB执行完后，复恢第一个事务
tm.resume(ts1);
doSomeThingB();
ts1.commit();//提交第一个事务
}
catch(RunTimeException ex){
ts1.rollback();//回滚第一个事务
}
finally{
//释放资源
}
}

使用PROPAGATION_NOT_SUPPORTED,也需要使用JtaTransactionManager作为事务管理器。

PROPAGATION_NEVER 总是非事务地执行，如果存在一个活动事务，则抛出异常

代码

//事务属性 PROPAGATION_REQUIRED
methodA(){
doSomeThingA();
methodB();
doSomeThingB();
}
//事务属性 PROPAGATION_NEVER
methodB(){
……
}

单独调用methodB，则非事务的执行。
调用methodA则会抛出异常
throw new IllegalTransactionStateException(
"Transaction propagation 'never' but existing transaction found");

PROPAGATION_NESTED如果一个活动的事务存在，则运行在一个嵌套的事务中. 如果没有活动事务, 则按TransactionDefinition.PROPAGATION_REQUIRED 属性执行

这是一个嵌套事务,使用JDBC 3.0驱动时,仅仅支持DataSourceTransactionManager作为事务管理器。需要JDBC 驱动的java.sql.Savepoint类。有一些JTA的事务管理器实现可能也提供了同样的功能。

使用PROPAGATION_NESTED，还需要把PlatformTransactionManager的nestedTransactionAllowed属性设为true;
而nestedTransactionAllowed属性值默认为false;

代码

//事务属性 PROPAGATION_REQUIRED
methodA(){
doSomeThingA();
methodB();
doSomeThingB();
}
//事务属性 PROPAGATION_NESTED
methodB(){
……
}

如果单独调用methodB方法，则按REQUIRED属性执行。

如果调用methodA方法，相当于下面的效果

代码

main(){
Connection con = null;
Savepoint savepoint = null;
try{
con = getConnection();
con.setAutoCommit(false);
doSomeThingA();
savepoint = con2.setSavepoint();
try
methodB();
}catch(RuntimeException ex){
con.rollback(savepoint);
}
finally{
//释放资源
}
doSomeThingB();
con.commit();
}
catch(RuntimeException ex){
con.rollback();
}
finally{
//释放资源
}
}

当methodB方法调用之前，调用setSavepoint方法，保存当前的状态到savepoint。如果methodB方法调用失败，则恢复到之前保存的状态。但是需要注意的是，这时的事务并没有进行提交，如果后续的代码(doSomeThingB()方法)调用失败，则回滚包括methodB方法的所有操作。

嵌套事务一个非常重要的概念就是内层事务依赖于外层事务。外层事务失败时，会回滚内层事务所做的动作。而内层事务操作失败并不会引起外层事务的回滚。

PROPAGATION_NESTED 与PROPAGATION_REQUIRES_NEW的区别:它们非常类似,都像一个嵌套事务，如果不存在一个活动的事务，都会开启一个新的事务。使用PROPAGATION_REQUIRES_NEW时，内层事务与外层事务就像两个独立的事务一样，一旦内层事务进行了提交后，外层事务不能对其进行回滚。两个事务互不影响。两个事务不是一个真正的嵌套事务。同时它需要JTA事务管理器的支持。
使用PROPAGATION_NESTED时，外层事务的回滚可以引起内层事务的回滚。而内层事务的异常并不会导致外层事务的回滚，它是一个真正的嵌套事务。DataSourceTransactionManager使用savepoint支持PROPAGATION_NESTED时，需要JDBC 3.0以上驱动及1.4以上的JDK版本支持。其它的JTA TrasactionManager实现可能有不同的支持方式。

PROPAGATION_REQUIRED应该是我们首先的事务传播行为。它能够满足我们大多数的事务需求。

hk2000c 2007-11-01 16:13 发表评论

Spring配置事务在DAO层和业务逻辑层

hk2000c — Thu, 01 Nov 2007 07:38:00 GMT

Spring通过AOP实现声明式事务管理。通常通过TransactionProxyFactoryBean设置Spring事务代理。我们需要一个目标对象包装在事务代理中。这个目标对象一般是一个普通Java对象的bean。当我们定义TransactionProxyFactoryBean时，必须提供一个相关的 PlatformTransactionManager的引用和事务属性。事务属性含有上面描述的事务定义。

PlatformTransactionManager：

HibernateTransactionManager需要一个SessionFactory的引用

JtaTransactionManager

一．把事务放置在了DAO层：

class="org.springframework.orm.hibernate3.HibernateTransactionManager">

层接口实现-->

class="com.vstsoft.querycompany.dao.impl.CompanyDAOImpl">

对DAO层的事务代理-->

class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">

PROPAGATION_REQUIRED

PROPAGATION_REQUIRED,readOnly

业务层接口实现，把DAO注入到Service里面-->

class="com.vstsoft.querycompany.service.impl.CompanyManageTarget">

对Service层的代理-->

class="org.springframework.aop.framework.ProxyFactoryBean">

com.vstsoft.querycompany.service.CompanyManage

配置struts访问，把service层注入到action里面-->

class="com.vstsoft.querycompany.web.action.CompanyAction" singleton="false">

二．把事务放置在了Service层：

class="org.springframework.transaction.jta.JtaTransactionManager" />

层接口实现-->

class="com.vstsoft.querycompany.dao.impl.CompanyDAOImpl">

对DAO层的代理-->

class="org.springframework.aop.framework.ProxyFactoryBean">

com.vstsoft.querycompany.dao.CompanyDAO

业务层接口实现，把DAO注入到Service里面-->

class="com.vstsoft.querycompany.service.impl.CompanyManageTarget">

代理业务层的事务管理-->

class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">

PROPAGATION_REQUIRED

PROPAGATION_REQUIRED,readOnly

配置struts访问，把service层注入到action里面-->

class="com.vstsoft.querycompany.web.action.CompanyAction" singleton="false">

在service层的接口实现CompanyManageImpl里面有个setData方法：按顺序执行数据查询，数据删除，数据插入数据库行为，如果哪一步出异常（运行时异常），事务回滚，只有所有行为都没成功，事务提交。

hk2000c 2007-11-01 15:38 发表评论

spring事务探索 [转]

hk2000c — Wed, 31 Oct 2007 17:36:00 GMT

spring自建事务管理模块。而且这个事务管理是一个抽象设计，可以应用到很多场合，包括普通的DataSource，jta，jms和hibernate上。

要正确使用spring的事务，首先需要了解spring在事务设计上的一些概念
统观spring事务，围绕着两个核心PlatformTransactionManager和TransactionStatus

PlatformTransactionManager 直译过来就是平台相关事务，这里的平台指的是“事务源”，包括刚才我说的DataSource，jta等等。这些无一不是一个事务源。广义的说，凡是可以完成事务性操作的对象，都可以设计出相对应的PlatformTransactionManager，只要这个事务源支持commit，rollback 和getTransaction语意。

查看spring代码，可以发现这些manager实现事务，就是调用事务源的事务操作方法

比如

HibernateTransactionManager
java代码:

protected void doCommit(DefaultTransactionStatus status) {
HibernateTransactionObject txObject = (HibernateTransactionObject) status.getTransaction();
if (status.isDebug()) {
logger.debug("Committing Hibernate transaction on session [" +
txObject.getSessionHolder().getSession() + "]";
}
try {
txObject.getSessionHolder().getTransaction().commit();
}
...

}

jdbc 的DataSourceTransactionManager
java代码:

protected void doCommit(DefaultTransactionStatus status) {
DataSourceTransactionObject txObject = (DataSourceTransactionObject) status.getTransaction();
Connection con = txObject.getConnectionHolder().getConnection();
if (status.isDebug()) {
logger.debug("Committing JDBC transaction on connection [" + con + "]";
}
try {
con.commit();
}
...
}

那么PlatformTransactionManager以什么依据处理事务呢？
是TransactionStatus
查看api发现这个接口有三个方法
isNewTransaction() ，isRollbackOnly()，setRollbackOnly()
PlatformTransactionManager 就是根据前两个方法决定是否要创建一个新事务，是要递交还是回滚。至于第三个方法是改变事务当前状态的，很多地方都要用到，偏偏 PlatformTransactionManager自身好像不怎么用，毕竟事务状态的改变是由程序员代码决定的，不需要一个manager多管闲事。

总结上面所说的，spring的事务由PlatformTransactionManager管理，manager最后调用事务源的方法来实现一个事务过程。而manager通过TransactionStatus 来决定如何实现。

接下去说spring事务中的TransactionTemplate和TransactionInterceptor

TransactionTemplate 其实和spring中其他的template的作用类似，起到化简代码的作用，不要被它那么长的名字吓倒了，事实上这个template并不是什么非常核心的对象。如果比较学究派的，可以去看看template设计模式，在此就不再对此赘述了。
为什么要有TransactionTemplate？先来看看如果没有TransactionTemplate，我们的代码该怎么写

先来看看spring reference中的一段代码
java代码:

DefaultTransactionDefinition def = new DefaultTransactionDefinition()
def.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED);

TransactionStatus status = transactionManager.getTransaction(def);

try {
// execute your business logic here
} catch (MyException ex) {
transactionManager.rollback(status);
throw ex;
}
transactionManager.commit(status);

这是直接使用transactionManager的例子，可以看到真正执行business logic 的地方是在try当中那段，前后的代码都是为了完成事务管理的。如果每个business logic都要写上那么一段，我肯定是疯了。我们翻出TransactionTemplate的代码看看他怎么化简了我们的代码

java代码:

public Object execute(TransactionCallback action) throws TransactionException {
TransactionStatus status = this.transactionManager.getTransaction(this);
Object result = null;
try {
result = action.doInTransaction(status);
}
catch (RuntimeException ex) {
// transactional code threw application exception -> rollback
rollbackOnException(status, ex);
throw ex;
}
catch (Error err) {
// transactional code threw error -> rollback
rollbackOnException(status, err);
throw err;
}
this.transactionManager.commit(status);
return result;
}

同上面的代码如出一辙，前后是事务处理代码，当中那段result = action.doInTransaction(status);是我们的应用代码。至于action是什么，全看各位的需要了。但是有一点要主要，如果利用TransactionTemplate，那么他不管你扔出什么异常都会回滚事务，但是回滚的是哪个事务呢？继续挖代码
java代码:

private void rollbackOnException(TransactionStatus status, Throwable ex) throws TransactionException {
if (logger.isDebugEnabled()) {
logger.debug("Initiating transaction rollback on application exception", ex);
}
try {
this.transactionManager.rollback(status);
}
catch (RuntimeException ex2) {
logger.error("Application exception overridden by rollback exception", ex);
throw ex2;
}
catch (Error err) {
logger.error("Application exception overridden by rollback error", ex);
throw err;
}
}

真相大白，是对template所持有的某个transactionManager进行回滚。所以如果你的应用代码用的是事务源a的一些资源，比如到服务器 a的一个datasource，但是你的transactionManager管理的是另一些资源，比如服务器b的一个datasource，代码铁定不会正常运行

特别是在一些多事务源的程序里，这点千万不能搞错。如果多个事务源之间要完成全局事务，还是老老实实用分布式事务管理服务吧（jta）

那么TransactionInterceptor是干什么的？这个是spring 的声明式事务的支持方式。因为用 TransactionTemplate要硬编码，而且调整事务策略很麻烦（不是说不能调。举个例子原来程序抛出异常A需要回滚，现在不需要要，我就可以把a catch吃掉。这时候template就不会回滚了。但是每次调整都要重写编码。）而用TransactionInterceptor就可以将这些调整写在配置中。我们再来挖TransactionInterceptor的代码

java代码:

public Object invoke(MethodInvocation invocation) throws Throwable {
// Work out the target class: may be null.
// The TransactionAttributeSource should be passed the target class
// as well as the method, which may be from an interface
Class targetClass = (invocation.getThis() != null) ? invocation.getThis().getClass() : null;

// Create transaction if necessary
TransactionInfo txInfo = createTransactionIfNecessary(invocation.getMethod(), targetClass);

Object retVal = null;
try {
// This is an around advice.
// Invoke the next interceptor in the chain.
// This will normally result in a target object being invoked.
retVal = invocation.proceed();
}
catch (Throwable ex) {
// target invocation exception
doCloseTransactionAfterThrowing(txInfo, ex);
throw ex;
}
finally {
doFinally(txInfo);
}
doCommitTransactionAfterReturning(txInfo);

return retVal;
}

万变不离其宗。

所以使用spring的事务管理需要作这些事
1，设置好事务源，比如DataSource，hibernate的session。如果有多个事务源要考虑他们之间是否有全局事务，如果有，老老实实用jta，否则就需要自己写一个manager了
2，设置manager，根据你的事务源选择对应的PlatformTransactionManager
3，选择实现事物的方式，用template还是interceptor。用template代码直观点，但是template所管辖的manager和你应用代码所用的事务源要一致。如果用interceptor千万注意，一定要调用interceptor那个bean，而不是原始的那个target。在坛子上我已经看到至少有两个朋友说spring事物不起作用，从配置和代码上看都正确，这时要好好查查，调用的bean是哪一个。
4，这个是设计问题了，推荐事务处于一个较高层次，比如service上的某个函数，而底层的dao可以不考虑事务，否则可能会出现事务嵌套，增加程序复杂度。

hk2000c 2007-11-01 01:36 发表评论

spring 事务支持

hk2000c — Wed, 31 Oct 2007 16:41:00 GMT

spring 事务支持，需要事务支持。

hk2000c 2007-11-01 00:41 发表评论

spring bean 继承父类property方法

hk2000c — Wed, 31 Oct 2007 08:32:00 GMT

xxAction继承BaseAction,BaseAction注入了一个CommonManager，BaseAction.commonSave()方法调用了commonManager。

本来想xxAction调用父类的commonSave方法将会导致commonManager为null的错误，因为jvm去初始化BaseAction时并不会去注入CommonManger。
其实解决这个问题只需要在子类xxAction bean配置文件中加上commonManager这个property，然后把父类BaseAction的commonManager 改为protected就 Ok了。这样初始化子类的时候会注入commonManager，调用commonSave方法也就不会抛出npe了。

配置文件中把xxAction 加上parent的配置也是可以的，这样会把父类的所有property都注入

hk2000c 2007-10-31 16:32 发表评论

增加CMS static page 预读功能

hk2000c — Tue, 30 Oct 2007 16:22:00 GMT

增加CMS static page 预读功能

hk2000c 2007-10-31 00:22 发表评论

用户密码使用动态密钥SHA-512位加密

hk2000c — Tue, 30 Oct 2007 06:17:00 GMT

用户密码使用动态密钥SHA-512位加密

hk2000c 2007-10-30 14:17 发表评论

系统会给出step by step 的配置表单

hk2000c — Tue, 30 Oct 2007 05:29:00 GMT

系统会给出step by step 的配置表单

配置比如密码密钥等关键数据

hk2000c 2007-10-30 13:29 发表评论

增加系统配置文件

hk2000c — Tue, 30 Oct 2007 05:23:00 GMT

增加系统配置文件

在 StartupListener 内

每次重启读取

hk2000c 2007-10-30 13:23 发表评论

支持动态读取系统配置Url列表

hk2000c — Tue, 30 Oct 2007 05:22:00 GMT

支持动态读取系统配置的url列表，标记为 static , 权限可配置

放在 StartupListener 内。

做到每次系统重启都自动更新，有校验匹配的功能。

hk2000c 2007-10-30 13:22 发表评论

增加用户名即时校验机制

hk2000c — Mon, 29 Oct 2007 08:00:00 GMT

增加用户名即时校验机制，可以即时查询用户名是否被占用。

hk2000c 2007-10-29 16:00 发表评论

加紧开发用户权限

hk2000c — Sat, 27 Oct 2007 09:29:00 GMT

完成了灵活表单开发。

加紧开发用户权限,修正用户列表，用户编辑，用户添加，数据库支持。

开发好以后就可以全面开发CMS系统了。

hk2000c 2007-10-27 17:29 发表评论

改进了spring 的校验机制

hk2000c — Fri, 26 Oct 2007 10:35:00 GMT

改进了spring 的校验机制

重写了几个类，使得应用程序更加自由，可以自定义formName,不用绑定pojo名字。

hk2000c 2007-10-26 18:35 发表评论

BaseCommandController initApplicationContext() 分析

hk2000c — Thu, 25 Oct 2007 17:12:00 GMT

BaseCommandController extends AbstractController extends WebContentGenerator WebContentGenerator extends WebApplicationObjectSupport extends ApplicationObjectSupport implements ApplicationContextAware

/**
* Subclasses can override this for custom initialization behavior.
* Gets called by setApplicationContext after setting the context instance.
*

Note: Does not get called on reinitialization of the context
* but rather just on first initialization of this object's context reference.
* @throws ApplicationContextException in case of initialization errors
* @throws BeansException if thrown by ApplicationContext methods
* @see #setApplicationContext
*/
protected void initApplicationContext() throws BeansException {
}

愿意为子类可以把初始化bean 动作放入此方法，可以自定义一些动作。

我们再来看看调用
public final void setApplicationContext(ApplicationContext context) throws BeansException {
  if (context == null && !isContextRequired()) {
   // Reset internal context state.
   this.applicationContext = null;
   this.messageSourceAccessor = null;
  }
  else if (this.applicationContext == null) {
   // Initialize with passed-in context.
   if (!requiredContextClass().isInstance(context)) {
    throw new ApplicationContextException(
      "Invalid application context: needs to be of type [" + requiredContextClass().getName() + "]");
   }
   this.applicationContext = context;
   this.messageSourceAccessor = new MessageSourceAccessor(context);
   initApplicationContext();
  }
  else {
   // Ignore reinitialization if same context passed in.
   if (this.applicationContext != context) {
    throw new ApplicationContextException(
      "Cannot reinitialize with different application context: current one is [" +
      this.applicationContext + "], passed-in one is [" + context + "]");
   }
  }
}

可以看到由 ApplicationObjectSupport 的 setApplicationContext 方法调用
而此方法为 ApplicationContextAware 的唯一接口方法，

public interface ApplicationContextAware {

/**
* Set the ApplicationContext that this object runs in.
* Normally this call will be used to initialize the object.
*

Invoked after population of normal bean properties but before an init callback such
* as {@link org.springframework.beans.factory.InitializingBean#afterPropertiesSet()}
* or a custom init-method. Invoked after {@link ResourceLoaderAware#setResourceLoader},
* {@link ApplicationEventPublisherAware#setApplicationEventPublisher} and
* {@link MessageSourceAware}, if applicable.
* @param applicationContext the ApplicationContext object to be used by this object
* @throws ApplicationContextException in case of context initialization errors
* @throws BeansException if thrown by application context methods
* @see org.springframework.beans.factory.BeanInitializationException
*/
void setApplicationContext(ApplicationContext applicationContext) throws BeansException;

}

此方法被 ApplicationContextAwareProcessor 的 postProcessBeforeInitialization 调用
ApplicationContextAwareProcessor implements BeanPostProcessor
public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
  if (bean instanceof ResourceLoaderAware) {
   ((ResourceLoaderAware) bean).setResourceLoader(this.applicationContext);
  }
  if (bean instanceof ApplicationEventPublisherAware) {
   ((ApplicationEventPublisherAware) bean).setApplicationEventPublisher(this.applicationContext);
  }
  if (bean instanceof MessageSourceAware) {
   ((MessageSourceAware) bean).setMessageSource(this.applicationContext);
  }
  if (bean instanceof ApplicationContextAware) {
   ((ApplicationContextAware) bean).setApplicationContext(this.applicationContext);
  }
  return bean;
}

hk2000c 2007-10-26 01:12 发表评论

spring validator 分析

hk2000c — Thu, 25 Oct 2007 16:48:00 GMT

以 BaseCommandController 为例
protected void initApplicationContext() {
  if (this.validators != null) {
   for (int i = 0; i < this.validators.length; i++) {
    if (this.commandClass != null && !this.validators[i].supports(this.commandClass))
     throw new IllegalArgumentException("Validator [" + this.validators[i] +
       "] does not support command class [" +
       this.commandClass.getName() + "]");
   }
  }
}

子类配置如下








public final void setValidator(Validator validator) {
  this.validators = new Validator[] {validator};
}

设置Validator数组

在初始化的时候，检验是否支持command 类型
this.validators[i].supports(this.commandClass)

此support 为 org.springframework.validation.Validator 的所有实现类的方法，检验支持检验类的动作。

举例配置




DefaultBeanValidator extends AbstractBeanValidator implements Validator

再看实现方法

   /**
     * Checks if the validatorFactory is configured to handle this class. Will
     * convert the class into a form name, suitable for commons validator.
     *
     * @return true if the validatorFactory supports the class,
     *         or false if not
     * @see #getFormName(Class)
     */
    public boolean supports(Class clazz) {
        boolean canSupport = validatorFactory.hasRulesForBean(getFormName(clazz), getLocale());
        if (log.isDebugEnabled()) {
            log.debug("validatorFactory " + (canSupport ? "does" : "does not")
                + " support class " + clazz + " with form name " + getFormName(clazz));
        }
        return canSupport;
    }

检验是否支持输入类

另一个方法
/**
     * If useFullyQualifiedClassName is false (default value), this function returns a
     * string containing the uncapitalized, short name for the given class
     * (e.g. myBean for the class com.domain.test.MyBean). Otherwise, it returns the value
     * returned by Class.getName().
     *
     * @param cls Class of the bean to be validated.
     * @return the bean name.
     */
    protected String getFormName(Class cls) {
        return (this.useFullyQualifiedClassName) ? cls.getName() : Introspector.decapitalize(ClassUtils.getShortName(cls));
    }
Introspector.decapitalize(ClassUtils.getShortName(cls) 获得按照西班牙命名法的form 名

这个方法本意是获得以类名为formName 的所有校验配置。

实际上有一个重大的设计缺陷

hk2000c 2007-10-26 00:48 发表评论

还要增加command 的记忆功能

hk2000c — Thu, 25 Oct 2007 09:01:00 GMT

还要增加command 的记忆功能，主要是为了表单验证失败以后，在服务器端控制表单内容不丢失问题。

hk2000c 2007-10-25 17:01 发表评论