BlogJava-捕风之巢-文章分类-java高级

事务隔离EJB的使用

捕风 — Mon, 15 Jan 2007 08:01:00 GMT

业务操作的事务性和事务隔离性，是 J2EE 开发中一个非常重要的功能。
比如，在业务操作中的系统日志和权限日志，就很好的体现了事务原子性和事务隔离的应用。

这里，主要讲一下事务隔离 EJB 的使用。

为了能在具有事务的 action 中调用不允许事务支持的外部系统 EJB ，如 UMSAO ，增加了事务隔离 EJB 。

Facade4IsolateService.java
Facade4IsolateServiceEJB.java
Facade4IsolateServiceHome.java
public interface Facade4IsolateService extends EJBLocalObject… {
     public void getReadPrivList(List permissionList, List userTypeList);
}
public class Facade4IsolateServiceEJB extends PafaSlsSessionBean {
     public void getReadPrivList(List permissionList, List userTypeList) {
        … …
    }
}
public interface Facade4IsolateServiceHome extends EJBLocalHome
{
     public Facade4IsolateService create() throws CreateException;
}

需要在相关文件中配置：

biz-context.xml
"ejb/test/Facade4IsolateService"在weblogic-ejb-jar.xml中配置，必须同名。

< bean id ="isolateEJB"         class ="com.test.app.lwc.service.remoting.access.ejb.LocalStatelessSessionProxyFactoryBean"      lazy-init ="true" >
         < property name ="jndiName" >
             < value > ejb/test/Facade4IsolateService value >
         property >
         < property name ="businessInterface" >
             < value >
                com.test.biz.service.ejb.Facade4IsolateService
             value >
         property >
         < property name ="jndiTemplate" >
             < ref local ="jndiTemplate" />
         property >
     bean >

weblogic-ejb-jar.xml
Facade4IsolateServiceEJB在ejb-jar.xml文件中设置。

< weblogic-enterprise-bean >
         < ejb-name > Facade4IsolateServiceEJB ejb-name >
         < stateless-session-descriptor >
             < pool >
                 < max-beans-in-free-pool > 500 max-beans-in-free-pool >
                 < initial-beans-in-free-pool > 1 initial-beans-in-free-pool >
             pool >
         stateless-session-descriptor >
         < enable-call-by-reference > True enable-call-by-reference >
     < local-jndi-name > ejb/test/Facade4IsolateService local-jndi-name >
     weblogic-enterprise-bean >

ejb-jar.xml

< session id ="Facade4IsolateServiceEJB" >
             < ejb-name > Facade4IsolateServiceEJB ejb-name >
             < local-home > com.test.biz.service.ejb.Facade4IsolateServiceHome local-home >
             < local > com.test.biz.service.ejb.Facade4IsolateService local >
             < ejb-class > com.test.biz.service.ejb.Facade4IsolateServiceEJB ejb-class >
             < session-type > Stateless session-type >
             < transaction-type > Container transaction-type >
             < env-entry >
                 < env-entry-name > ejb/BeanFactoryPath env-entry-name >
                 < env-entry-type > java.lang.String env-entry-type >
                 < env-entry-value > biz-context.xml env-entry-value >
             env-entry >
         session >

设置事务的隔离属性

< container-transaction >
             < method >
                 < ejb-name > Facade4IsolateServiceEJB ejb-name >
                 < method-name > * method-name >
               method >
               < trans-attribute > NotSupported trans-attribute >
         container-transaction >

捕风 2007-01-15 16:01 发表评论

ant结合junit进行软件自动测试

捕风 — Tue, 28 Nov 2006 09:11:00 GMT

持续集成实践三，灵感来自于Martin Fowler的“持续集成“一文。可以在www.martinfowler.com看到，国内有人翻译成了中文。

本文假设读者具备如下知识：

1、熟练ant进行java工程编译（参考本人“ant编译java工程”一文）

2、junit知识，看看www.junit.org

准备：

1、www.junit.org下载junit.jar

2、xml.apache.org下载xalan.jar（ant 的 juntreport需要用到，xalan最好版本大于2.0，不然你还要下载其他的java库）

把junit.jar、xalan.jar拷贝到$ANT_HOME/lib/下面，并且最好加到系统CLASSPATH（junit.jar是肯定要的，xalan.jar就不清楚了）。

对自己的程序添加junit测试程序，此处请参考www.junit.org的文档，很简单的。

然后在build.xml中添加如下指令,很多东西略过，所以强烈要求读者先完成本人“ant编译java工程”一文）

现在运行ant test，看看reports/下面是不是有了生成的单元测试结果的文件了？

如果有问题可以用ant -debug test看看问题出在哪里？

另外更改源程序，让程序通过测试和通不过测试看看生成的结果如何？

捕风 2006-11-28 17:11 发表评论

使用Ant运行本地程序(转)

捕风 — Tue, 28 Nov 2006 09:09:00 GMT

摘要: . 使用Ant运行windows的批处理文件要在 Ant ... 阅读全文

捕风 2006-11-28 17:09 发表评论

Ant+Tomcat自动部署

捕风 — Thu, 23 Nov 2006 00:59:00 GMT

今天研究对象是Ant，用于对msms系统进行Tomcat的自动部署。

遇到一个怪问题，百思不得其解：
通过ant depoly可以把msms.war部署到tomcat上。当然，要求这时候webapps下面没有msms目录。
看tomcat的纪录，加载msms.war正常，网页也可以打开。

通过ant undeploy，可以把msms卸载。Tomcat显示：
Undeploying context [/msms]
正常卸载了。问题是，去看webapps目录下面，居然有一个msms目录的残骸，里面保留的目录是
WEB-INF\lib
有以下几个文件残留着：
commons-digester.jar
commons-validator.jar
struts.jar

这时候msms目录也无法手工删除，必须停掉tomcat后才能删除。

我装的tomcat是5.5。不知道是否还有人遇到过这种情况，我反正是晕了。

build.properties文件如下：
tomcat.dir=C:/ApacheGroup/Tomcat5.5
tomcat.webapps=C:/ApacheGroup/Tomcat5.5/webapps
tomcat.manager.url=http://localhost:8080/manager
tomcat.manager.username=admin
tomcat.manager.password=xxxxxxxx

build.xml文件如下：































































































































      ***********************************************************
      **** One or more tests failed! Check the output ... ****
      ***********************************************************


















































只有Windows上才会有的问题，
创建META-INF目录，在目录里新建context.xml，加入如下内容

昨天的错误至今无法修正，即使重装了Tomcat也不行。

不过，deploy到两台linux服务器上倒都成功了。






















这里跟昨天的代码有一点不一样：
1、localWar改成了war。
原来更新远程服务器的时候，总是显示更新成功，但是到webapps目录下总是没有相应的war文件，通过调用
ant list-web
发现，有一个context-path是dist/msms，而且是stop状态。哦，原来localWar的意思不是指开发的机器的local path，而是指把这个war被写到服务器的什么地方。改成war就正常了。

2、不需要判断是否已经deploy进而调用undeploy了，直接通过update="true"更新就可以了。

捕风 2006-11-23 08:59 发表评论

Ant基本使用指南

捕风 — Thu, 23 Nov 2006 00:56:00 GMT

摘要: 1 Ant是什么？ Apache Ant 是一个基于 Java的生成工具。生成工具在软件开发中用来将源代码和其他输入文件转换为可执行文件的形式（也有可能转换为可安装的产品映像形式）。随着应用程序的生成过程变得更加复杂，确保在每次生成期间都使用精确相同的生成步骤，同时实现尽可能多的自动化，以便及时产生一致的生成版本 2下载、安装Ant 安装Ant 下载.zip文件，... 阅读全文

捕风 2006-11-23 08:56 发表评论

了解AOP(一)

捕风 — Wed, 25 Oct 2006 02:06:00 GMT

原文:http://www.javaworld.com/javaworld/jw-01-2002/jw-0118-aspect.html

了解AOP（第一部分）--用面向方面的编程方式分离软件关注点

摘要

多数软件系统都包含几个跨越多个模块的关注点。用面向对象技术实现这些关注点会使系统难以实现，难以理解，并且不利于软件的演进。新的AOP（面向角度的编程方法）利用模块化来分离软件中横切多模块的关注点。使用AOP，你可以建立容易设计，易于理解和维护的系统。此外，AOP可以带来更高的产出，更好的质量，更好的扩展性，这篇文章是这个系列里三篇文章中的第一章，介绍AOP的概念和它所解决的问题。

作者：Ramnivas Laddad

一个关注点就是一个特定的目的、一块我们感兴趣的的区域。从技术的角度来说，一个典型的软件系统包含一些核心的关注点和系统级的关注点。举个例子来说，一个信用卡处理系统的核心关注点是借贷/存入处理，而系统级的关注点则是日志，事务完整性，授权，安全性及性能问题等，许多关注点——我们叫它横切关注点——会在多个模块中出现，使用现有的编程方法，横切关注点会横越多个模块，结果是使系统难以设计、理解、实现和演进。

AOP（面向角度的编程方式）能够比上述方法更好的分离系统关注点，从而提供模块化的横切关注点。

在这篇文章里——关于AOP的三篇文章的第一章，我首先会解释横切关注点在一些即使是中等复杂度的软件系统中也会引起的问题，接着我会介绍AOP的核心概念并演示AOP是怎样解决横切关注点问题的。

软件编程方法的演进

在计算机科学的早期阶段，开发人员使用直接的机器级代码来编程，不幸的是，程序员得花费更多时间来考虑一种特定机器的指令集而不是手中需要解决的问题本身。慢慢的我们转而使用允许对底层机器做某种抽象的高级语言。然后是结构化语言，我们可以把问题分解成一些必要的过程来完成任务。但是，随着复杂程度的增加，我们又需要更适合的技术。面向对象的编程方式（OOP）使我们可以把系统看作是一批相互合作的对象。类允许我们把实现细节隐藏在接口下。多态性为相关概念提供公共的行为和接口，并允许特定的组件在无需访问基础实现的前提下改变特定行为。

编程方法和语言决定了我们和计算机交流的方式。每一种新的方法学都提出一种新的分解问题的方法：机器码、伪代码、过程和类等。每种新的方法学都使得从系统需求到编程概念的映射更加自然。编程方法学的发展让我们可以建立更加复杂的系统，这句话反过来说也对，我们能够建立更加复杂的系统是因为这些技术允许我们处理这种复杂度。

现在，大多数软件项目都选择OOP的编程方式。确实，OOP已经表明了它处理一般行为的能力，但是，我们一会儿会看到（或许你已经感觉到了）， OOP不能很好的处理横越多个——经常是不相关的——模块的行为，相比之下，AOP填补了这个空白，它很可能会是编程方法学发展的下一个里程碑。

把系统看作一批关注点

我们可以把一个复杂的系统看作是由多个关注点来组合实现的，一个典型的系统可能会包括几个方面的关注点，如业务逻辑，性能，数据存储，日志和调试信息，授权，安全，线程，错误检查等，还有开发过程中的关注点，如易懂，易维护，易追查，易扩展等，图一演示了由不同模块实现的一批关注点组成了一个系统。

图 1. 把模块作为一批关注点来实现

　
图二把需求比作一束穿过三棱镜的光，我们让需求之光通过关注点鉴别三棱镜，就会区别出每个关注点，同样的方法也适用于开发阶段的关注点。

图 2. 关注点分解: 三棱镜法则

开发人员建立一个系统以满足多个需求，我们可以大致的把这些需求分类为核心模块级需求和系统级需求。很多系统级需求一般来说是相互独立的，但它们一般都会横切许多核心模块。举个例子来说，一个典型的企业应用包含许多横切关注点，如验证，日志，资源池，系统管理，性能及存储管理等，每一个关注点都牵涉到几个子系统，如存储管理关注点会影响到所有的有状态业务对象。

让我们来看一个简单，但是具体的例子，考虑一个封装了业务逻辑的类的实现框架：

代码:

public class SomeBusinessClass extends OtherBusinessClass {
// 核心数据成员

// 其它数据成员：日志流，保证数据完整性的标志位等

// 重载基类的方法

public void performSomeOperation(OperationInformation info) {
// 安全性验证

// 检查传入数据是否满足协议

// 锁定对象以保证当其他线程访问时的数据完整性

// 检查缓存中是否为最新信息

// 纪录操作开始执行时间

// 执行核心操作

// 纪录操作完成时间

// 给对象解锁
}

// 一些类似操作

public void save(PersitanceStorage ps) {
}

public void load(PersitanceStorage ps) {
}
}

在上面的代码中，我们注意到三个问题，首先，其它数据成员不是这个类的核心关注点，第二，performSomeOperation()的实现做了许多核心操作之外的事，它要处理日志，验证，线程安全，协议验证和缓存管理等一些外围操作，而且这些外围操作同样也会应用于其他类，第三，save() 和load()执行的持久化操作是否构成这个类的核心清楚的。

横切关注点的问题

虽然横切关注点会跨越多个模块，但当前的技术倾向于使用一维的方法学来处理这种需求，把对应需求的实现强行限制在一维的空间里。这个一维空间就是核心模块级实现，其他需求的实现被嵌入在这个占统治地位的空间，换句话说，需求空间是一个n维空间，而实现空间是一维空间，这种不匹配导致了糟糕的需求到实现的映射

表现
用当前方法学实现横切关注点是不好的，它会带来一些问题，我们可以大致把这些问题分为两类:

代码混乱：软件系统中的模块可能要同时兼顾几个方面的需要。举例来说，开发者经常要同时考虑业务逻辑，性能，同步，日志和安全等问题，兼顾各方面的需要导致相应关注点的实现元素同时出现，引起代码混乱。
代码分散：由于横切关注点，本来就涉及到多个模块，相关实现也就得遍布在这些模块里，如在一个使用了数据库的系统里，性能问题就会影响所有访问数据库的模块。这导致代码分散在各处

结果

混乱和分散的代码会在多个方面影响系统的设计和开发：

可读性差：同时实现几个关注点模糊了不同关注点的实现，使得关注点与其实现之间的对应关系不明显。
低产出：同时实现几个关注点把开发人员的注意力从主要的转移到外围关注点，导致产能降低。
低代码重用率：由于这种情况下，一个模块实现多个关注点，其他需要类似功能的系统不能马上使用该模块，进一步降低了产能。
代码质量差：混乱的代码掩盖了代码中隐藏的问题。而且，由于同时要处理多个关注点，应该特别注意的关注点得不到应有的关注

难以扩展：狭窄的视角和有限的资源总是产生仅注意当前关注点的设计。新的需求导致从新实现。由于实现不是模块化的，就是说实现牵涉到多个模块，为了新需求修改子系统可能会带来数据的不一致，而且还需相当规模测试来保证这些修改不会带来bug。

当前解决方法

由于多数系统中都包含横切关注点，自然的已经形成了一些技术来模块化横切关注点的实现，这些技术包括：混入类，设计模式和面向特定问题域的解决方式

使用混入类，你可以推迟关注点的最终实现。基本类包含一个混入类的实例，允许系统的其他部分设置这个实例，举个例子来说，实现业务逻辑的类包含一个混入的logger，系统的其他部分可以设置这个logger已得到合适的日志类型，比如logger可能被设置为使用文件系统或是消息中间件.在这种方式下，虽然日志的具体实现被推迟啦，基本类还是得包含在所有的写日志的点调用日志操作和控制日志信息的代码。

行为型设计模式，如Visitor和Template模式，也允许你推迟具体实现。但是也就像混入类一样，操作的控制——调用visitor或template的逻辑——仍然留给了基本类

面向特定问题域的解决方式，如框架和应用服务器，允许开发者用更模块化的方式处理某些横切关注点。比如EJB(Enterprise JavaBean，企业级javabean)架构,可以处理安全，系统管理，性能和容器管理的持久化（container-managed persistence）等横切关注点。Bean的开发者仅需关心业务逻辑，而部署者仅需关心部署问题，如bean与数据库的映射。但是大多数情况下，开发者还是要了解存储结构。这种方式下，你用基于XML的映射关系描述器来实现于数据持久化相关的横切关注点。

面向特定问题域的解决方式提供了解决特定问题的专门机制，它的缺点是对于每一种这样的解决方式开发人员都必须重新学习，另外，由于这种方式是特定问题域相关的，属于特定问题域之外的横切关注点需要特殊的对待

设计师的两难局面

好的系统设计师不仅会考虑当前需求，还会考虑到可能会有的需求以避免到处打补丁。这样就存在一个问题，预知将来是很困难的，如果你漏过了将来可能会有的横切关注点的需求，你将会需要修改或甚至是重新实现系统的许多部分；从另一个角度来说，太过于关注不一定需要的需求会导致过分设计（overdesigned）的，难以理解的，臃肿的系统。所以系统设计师处在这么一个两难局面中：怎么设计算是过分设计？应该宁可设计不足还是宁可过分设计？

举个例子来说，设计师是否应该在系统中包含现在并不需要的日志机制？如果是的话，哪里是应该写日志的点？日志应该记录那些信息？相似的例子还有关于性能的优化问题，我们很少能预先知道瓶颈的所在。常用的方法是建立系统，profile它，然后翻新系统以提高性能，这种方式可能会依照 profiling修改系统的很多部分，此外，随着时间的流逝，由于使用方式的变化，可能还会产生新的瓶颈，类库设计师的任务更困难，因为他很难设想出所有对类库的使用方式。

总而言之，设计师很难顾及到系统可能需要处理的所有关注点。即使是在已经知道了需求的前提下，某些建立系统时需要的细节也可能不能全部得到。整体设计就面临着设计不足/过分设计的两难局面。

AOP基础

到目前为止的讨论说明模块化横切关注点是有好处的。研究人员已经尝试了多种方法来实现这个任务，这些方法有一个共同的主题：分离关注点。AOP是这些方法中的一种，它的目的是清晰的分离关注点来解决以上提到的问题。

AOP，从其本质上讲，使你可以用一种松散耦合的方式来实现独立的关注点，然后，组合这些实现来建立最终系统。用它所建立的系统是使用松散耦合的，模块化实现的横切关注点来搭建的。与之对照，用OOP建立的系统则是用松散耦合的模块化实现的一般关注点来实现的。在AOP终，这些模块化单元叫方面（aspect），而在OOP中，这些一般关注点的实现单元叫做类。

AOP包括三个清晰的开发步骤：

方面分解：分解需求提取出横切关注点和一般关注点。在这一步里，你把核心模块级关注点和系统级的横切关注点分离开来。就前面所提到的信用卡例子来说，你可以分解出三个关注点：核心的信用卡处理，日志和验证。
关注点实现：各自独立的实现这些关注点，还用上面信用卡的例子，你要实现信用卡处理单元，日志单元和验证单元。
方面的重新组合：在这一步里，方面集成器通过创建一个模块单元——方面来指定重组的规则。重组过程——也叫织入或结合——则使用这些信息来构建最终系统，还拿信用卡的那个例子，你可以指定（用某种AOP的实现所提供的语言）每个操作的开始和结束需要纪录，并且每个操作在涉及到业务逻辑之前必须通过验证。

图 3. AOP 开发的步骤

AOP与OOP的不同关键在于它处理横切关注点的方式，在AOP中，每个关注点的实现都不知道其它关注点是否会‘关注’它，如信用卡处理模块并不知道其它的关注点实现正在为它做日志和验证操作。它展示了一个从OOP转化来的强大的开发范型。

注意：一个AOP实现可以借助其它编程范型作为它的基础，从而原封不动的保留其基础范型的优点。例如，AOP可以选择OOP作为它的基础范型，从而把OOP善于处理一般关注点的好处直接带过来。用这样一种实现，独立的一般关注点可以使用OOP技术。这就像过程型语言是许多OOP语言的基础一样。

织入举例
织入器——一个处理器——组装一个个关注点（这个过程叫做织入）。就是说，它依照提供给它的规则把不同的执行逻辑段混编起来。

为了说明代码织入，让我们回到信用卡处理的例子，为了简单起见，我们只考虑两个操作：存入和取出，并且我们假设已经有了一个合适的logger.

来看一下下面的信用卡模块：

代码:

public class CreditCardProcessor {
public void debit(CreditCard card, Currency amount)
throws InvalidCardException, NotEnoughAmountException,
CardExpiredException {
// 取出逻辑
}

public void credit(CreditCard card, Currency amount)
throws InvalidCardException {
// 存入逻辑

}
}

下面是日志接口

代码:

public interface Logger {
public void log(String message);
}

所需组合需要如下织入规则，这里用自然语言来表达（本文的后面会提供这些织入规则的程序版本）：
[list=a]

纪录每个公共操作的开始
纪录每个公共操作的结束
纪录所有公共方法抛出的异常

织入器就会使用这些织入规则和关注点实现来产生与如下代码有相同效果的代码：

代码:

public class CreditCardProcessorWithLogging {
Logger _logger;

public void debit(CreditCard card, Money amount)
throws InvalidCardException, NotEnoughAmountException,
CardExpiredException {
_logger.log("Starting CreditCardProcessor.credit(CreditCard,
Money) "
+ "Card: " + card + " Amount: " + amount);
// 取出逻辑
_logger.log("Completing CreditCardProcessor.credit(CreditCard,
Money) "
+ "Card: " + card + " Amount: " + amount);
}

public void credit(CreditCard card, Money amount)
throws InvalidCardException {
System.out.println("Debiting");
_logger.log("Starting CreditCardProcessor.debit(CreditCard,
Money) "
+ "Card: " + card + " Amount: " + amount);
// 存入逻辑
_logger.log("Completing CreditCardProcessor.credit(CreditCard,
Money) "
+ "Card: " + card + " Amount: " + amount);

}
}

AOP语言剖析

就像其他编程范型的实现一样，AOP的实现有两部分组成：语言规范和实现。语言规范描述了语言的基础单元和语法。语言实现则按照语言规范来验证代码的正确性并把代码转成目标机器的可执行形式。这一节，我来解释一下AOP组成部分。

AOP语言规范
从抽象的角度看来，一种AOP语言要说明下面两个方面：

关注点的实现：把每个需求映射为代码，然后，编译器把它翻译成可执行代码，由于关注点的实现以指定过程的形式出现，你可以使用传统语言如C，C++，Java等。
织入规则规范：怎样把独立实现的关注点组合起来形成最终系统呢？为了这个目的，需要建立一种语言来指定组合不同的实现单元以形成最终系统的规则，这种指定织入规则的语言可以是实现语言的扩展，也可以是一种完全不同的语言。

AOP语言的实现

AOP的编译器执行两步操作：

组装关注点。
把组装结果转成可执行代码

AOP实现可以用多种方式实现织入，包括源码到源码的转换。它预处理每个方面的源码产生织入过的源码，然后把织入过的源码交给基础语言的编译器产生最终可执行代码。比如，使用这种方式，一个基于Java的AOP实现可以先把不同的方面转化成Java源代码，然后让Java编译器把它转化成字节码。也可以直接在字节码级别执行织入；毕竟，字节码本身也是一种源码。此外，下面的执行系统——Java虚拟机——也可以是方面认知的，基于Java的AOP 实现如果使用这种方式的话，虚拟机可以先装入织入规则，然后对后来装入的类都应用这种规则，也就是说，它可以执行just-in-time的方面织入。

AOP的好处

AOP可帮助我们解决上面提到的代码混乱和代码分散所带来的问题，它还有一些别的好处：

块化横切关注点：AOP用最小的耦合处理每个关注点，使得即使是横切关注点也是模块化的。这样的实现产生的系统，其代码的冗余小。模块化的实现还使得系统容易理解和维护
系统容易扩展：由于方面模块根本不知道横切关注点，所以很容易通过建立新的方面加入新的功能，另外，当你往系统中加入新的模块时，已有的方面自动的横切进来，使系统的易于扩展
设计决定的迟绑定：还记得设计师的两难局面吗？使用AOP,设计师可以推迟为将来的需求作决定，因为它可以把这种需求作为独立的方面很容易的实现。
更好的代码重用性：由于AOP把每个方面实现为独立的模块，模块之间是松散耦合的，举例来说，你可以用另外一个独立的日志写入器方面（替换当前的）把日志写入数据库，以满足不同的日志写入要求。
总的来说，松散耦合的实现意味着更好的代码重用性， AOP在使系统实现松散耦合这一点上比OOP做得更好。

AspectJ:一个Java的AOP实现

AspectJ是一个可免费获得的由施乐公司帕洛阿尔托研究中心（Xerox PARC）开发Java的AOP实现，它是一个多功能的面向方面的Java扩展。它使用Java作为单个关注点的实现语言，并扩展Java以指定织入规则。这些规则是用切入点（pointcuts）、联结点（join points），通知（advice）和方面（aspect）来说明的。联结点是定义在程序执行过程之间的点，切入点由用来指定联结点的语言构造，通知定义了要在切入点上执行的代码片，而方面则是这些基础元素的组合。

另外，AspectJ允许以多种方式用方面和类建立新的方面，你可以引入新的数据成员和方法，或是声明一个新的类来继承和实现另外的类或接口。

AspectJ的织入器——AspectJ的编译器——负责把不同的方面组合在一起，由于由AspectJ编译器建立的最终系统是纯Java字节码，它可以运行在任何符合Java标准的虚拟机上。而且，AspectJ还提供了一些工具如调试器和Java IDE集成等，我将会在本系列的第二、三部分详细讲解这些。

下面是我在上面用自然语言描述的日志方面的织入规则的AspectJ实现，由于我将会在第二部分详细介绍AspectJ，所以如果你不能透彻的看懂它的话也不必担心。关键是你应该注意到信用卡处理过程本身一点都不知道日志的事。

代码:

public aspect LogCreditCardProcessorOperations {
Logger logger = new StdoutLogger();

pointcut publicOperation():
execution(public * CreditCardProcessor.*(..));

pointcut publicOperationCardAmountArgs(CreditCard card,
Money amount):
publicOperation() && args(card, amount);

before(CreditCard card, Money amount):
publicOperationCardAmountArgs(card, amount) {
logOperation("Starting",
thisjoin point.getSignature().toString(), card, amount);
}

after(CreditCard card, Money amount) returning:
publicOperationCardAmountArgs(card, amount) {
logOperation("Completing",
thisjoin point.getSignature().toString(), card, amount);
}

after (CreditCard card, Money amount) throwing (Exception e):
publicOperationCardAmountArgs(card, amount) {
logOperation("Exception " + e,
thisjoin point.getSignature().toString(), card, amount);
}

private void logOperation(String status, String operation,
CreditCard card, Money amount) {
logger.log(status + " " + operation +
" Card: " + card + " Amount: " + amount);
}
}

我需要AOP吗？

AOP仅仅是解决设计上的缺点吗？在AOP里，每个关注点的实现的并不知道是否有其它关注点关注它，这是AOP和OOP的主要区别，在AOP里，组合的流向是从横切关注点到主关注点，而OOP则相反，但是，OOP可以和AOP很好的共存。比如，你可以使用一个混入类来做组合，既可以用AOP实现，也可以用OOP实现，这取决你对AOP的接受程度。在这两种情况下，实现横切关注点的混入类实现都无需知道它自己是被用在类中还是被用在方面中。举个例子来说，你可以把一个日志写入器接口用作某些类的混入类或是用作一个日志方面。因而，从OOP到AOP是渐进的。

了解AOP

在这篇文章里，你看到了横切关系带来的问题，这些问题的当前解决方法，以及这些方法的缺点。你也看到了AOP是怎样克服这些缺点的。AOP的编程方式试图模块化横切关注点的实现，提供了一个更好更快的软件开发方式。

如果你的系统中涉及到多个横切关注点，你可以考虑进一步了解AOP,它的实现，它的好处。AOP很可能会是编程方式的下一个里程碑。请继续关注本系列的第二、第三部分。

捕风 2006-10-25 10:06 发表评论

Spring AOP中文教程

捕风 — Wed, 25 Oct 2006 02:04:00 GMT

这是在网上发现的一篇关于Spring AOP编程的教程，读完这篇文章后，Spring AOP不再难以理解，因此我把它译成中文，推荐给Spring AOP的初学者。这是译文的链接。

AOP正在成为软件开发的下一个圣杯。使用AOP，你可以将处理aspect的代码注入主程序，通常主程序的主要目的并不在于处理这些aspect。AOP可以防止代码混乱。
为了理解AOP如何做到这点，考虑一下记日志的工作。日志本身不太可能是你开发的主程序的主要任务。如果能将“不可见的”、通用的日志代码注入主程序中，那该多好啊。AOP可以帮助你做到。
Spring framework是很有前途的AOP技术。作为一种非侵略性的，轻型的AOP framework，你无需使用预编译器或其他的元标签，便可以在Java程序中使用它。这意味着开发团队里只需一人要对付AOP framework，其他人还是象往常一样编程。
AOP是很多直觉难以理解的术语的根源。幸运的是，你只要理解三个概念，就可以编写AOP模块。这三个概念是：advice，pointcut和 advisor。advice是你想向别的程序内部不同的地方注入的代码。pointcut定义了需要注入advice的位置，通常是某个特定的类的一个 public方法。advisor是pointcut和advice的装配器，是将advice注入主程序中预定义位置的代码。

既然我们知道了需要使用advisor向主要代码中注入“不可见的”advice，让我们实现一个Spring AOP的例子。在这个例子中，我们将实现一个before advice，这意味着advice的代码在被调用的public方法开始前被执行。以下是这个before advice的实现代码：

代码:

package com.company.springaop.test;

import java.lang.reflect.Method;
import org.springframework.aop.MethodBeforeAdvice;

public class TestBeforeAdvice implements MethodBeforeAdvice {

public void before(Method m, Object[] args, Object target)
throws Throwable {
System.out.println("Hello world! (by "
+ this.getClass().getName()
+ ")");
}
}

接口MethodBeforeAdvice只有一个方法before需要实现，它定义了advice的实现。before方法共用三个参数，它们提供了相当丰富的信息。参数Method m是advice开始后执行的方法。方法名称可以用作判断是否执行代码的条件。Object[] args是传给被调用的public方法的参数数组。当需要记日志时，参数args和被执行方法的名称，都是非常有用的信息。你也可以改变传给m的参数，但要小心使用这个功能；编写最初主程序的程序员并不知道主程序可能会和传入参数的发生冲突。Object target是执行方法m对象的引用。

在下面的BeanImpl类中，每个public方法调用前，都会执行advice：

代码:

package com.company.springaop.test;

public class BeanImpl implements Bean {

public void theMethod() {
System.out.println(this.getClass().getName()
+ "." + new Exception().getStackTrace()[0].getMethodName()
+ "()"
+ " says HELLO!");
}
}

类BeanImpl实现了下面的接口Bean：

代码:

package com.company.springaop.test;

public interface Bean {
public void theMethod();
}

虽然不是必须使用接口，但面向接口而不是面向实现编程是良好的编程实践，Spring也鼓励这样做。

pointcut和advice通过配置文件来实现，因此，接下来你只需编写主方法的Java代码：

代码:

package com.company.springaop.test;

import org.springframework.context.ApplicationContext;
import org.springframework.context.support.FileSystemXmlApplicationContext;

public class Main {

public static void main(String[] args) {
//Read the configuration file
ApplicationContext ctx
= new FileSystemXmlApplicationContext("springconfig.xml");

//Instantiate an object
Bean x = (Bean) ctx.getBean("bean");

//Execute the public method of the bean (the test)
x.theMethod();
}
}

我们从读入和处理配置文件开始，接下来马上要创建它。这个配置文件将作为粘合程序不同部分的“胶水”。读入和处理配置文件后，我们会得到一个创建工厂ctx。任何一个Spring管理的对象都必须通过这个工厂来创建。对象通过工厂创建后便可正常使用。

仅仅用配置文件便可把程序的每一部分组装起来。

代码:

com.company.springaop.test.Bean

theAdvisor

com\.company\.springaop\.test\.Bean\.theMethod

四个bean定义的次序并不重要。我们现在有了一个advice，一个包含了正则表达式pointcut的advisor，一个主程序类和一个配置好的接口，通过工厂ctx，这个接口返回自己本身实现的一个引用。

BeanImpl和TestBeforeAdvice都是直接配置。我们用一个唯一的ID创建一个bean元素，并指定了一个实现类。这就是全部的工作。

advisor通过Spring framework提供的一个RegexMethodPointcutAdvisor类来实现。我们用advisor的一个属性来指定它所需的 advice-bean。第二个属性则用正则表达式定义了pointcut，确保良好的性能和易读性。

最后配置的是bean，它可以通过一个工厂来创建。bean的定义看起来比实际上要复杂。bean是ProxyFactoryBean的一个实现，它是Spring framework的一部分。这个bean的行为通过一下的三个属性来定义：

属性proxyInterface定义了接口类。
属性target指向本地配置的一个bean，这个bean返回一个接口的实现。
属性interceptorNames是唯一允许定义一个值列表的属性。这个列表包含所有需要在beanTarget上执行的advisor。注意，advisor列表的次序是非常重要的。

Spring工具

虽然你可以手工修改Ant构建脚本，但使用SpringUI（译注：SpringUI现在是Spring framework的一部分，并改名为spring-ide），使用Spring AOP变得很简单，只要点点鼠标即可。你可以把SpringUI安装成Eclipse的一个plug-in。然后，你只需在你的project上右击鼠标，并选择“add Spring Project Nature”。在project属性中，你可以在“Spring Project”下添加Spring配置文件。在编译前把下面的类库加入project：aopalliance.jar，commons- logging.jar，jakarta-oro-2.0.7.jar和spring.jar。运行程序时你会看到下面的信息：

... (logging information)
Hello world! (by com.company.springaop.test.TestBeforeAdvice)
com.company.springaop.test.BeanImpl.theMethod() says HELLO!

优点和缺点

Spring比起其他的framework更有优势，因为除了AOP以外，它提供了更多别的功能。作为一个轻型framework，它在J2EE 不同的部分都可以发挥作用。因此，即使不想使用Spring AOP，你可能还是想使用Spring。另一个优点是，Spring并不要求开发团队所有的人员都会用它。学习Spring应该从Spring reference的第一页开始。读了本文后，你应该可以更好地理解Spring reference了。Spring唯一的缺点是缺乏更多的文档，但它的mailing list是个很好的补充，而且会不断地出现更多的文档。

捕风 2006-10-25 10:04 发表评论

关于AspectJ 中的pointcut 语法

捕风 — Thu, 19 Oct 2006 09:28:00 GMT

关于AspectJ 中的pointcut 语法

    这两天忙着看AspectJ in Action 为了补一下AOP知识。看了Spring 2.0的规范，其中AOP部分已经基本融合了AspectJ，看来有必要看一看AspectJ了。
   看了很多AOP的文章了，AOP这两年发展的很慢，没有什么新意，现在到处都是SOA，SCA了，不过研究了一下，觉得还是很有帮助的。尤其是增加系统的契约性和模块的独立性来说，很有帮助。
   当然，学东西，基础很重要。下面就说说AspectJ中的基本语法，有兴趣的可以看看AspectJ in Action。
   先来说说pointcut，从字面的意思说的是切面的意思。也就是横切的时候，会有哪些执行点会被识别。只有先识别了，才能执行相应的Advice。
   基本的定义如下：

   public pointcut accountOperations:call(* Account.*(..))

   1.通配符和pointcut 操作符

* 表示任何数量的字符，除了(.)
.. 表示任何数量的字符包括任何数量的(.)
+ 描述指定类型的任何子类或者子接口

    同java一样，提供了一元和二元的条件表达操作符。
    一元操作符：!
      二元操作符：||和&&
      优先权同java

      2.签名语法

类型签名样式

主要的例子:
Account                              类型Account
    *Account                             使用Account名称结束的类型，如SavingsAccount和CheckingAccount
    java.*.Date                         类型Date在任何直接的java子包中，如java.util.Date和java.sql.Date
java..*                                 任何在java包或者所有子包中的类型，如java.awt和java.util或者java.awt.event 和java.util.logging
    javax..*Model+                   所有javax包或者子包中以Model结尾的类型和其所有子类，如TableModel,TreeModel。
！vector                             所有除了Vector的类型
Vector|| Hashtable              Vector或者Hashtable类型
java.util.RandomAccess+    实现RandomAccess和List的所有子类
   && java.util.List+

   方法和构造器签名模式

public void Collection.clear()：
在Collection中同样签名的clear方法

public void Account.debit(float) throws InsufficientBalanceException：
Account中同样签名的debit方法

public void Account.set*(*)
Account中以set开头，并且只有一个参数类型的方法

public void Account.*()
Account中所有的没有参数的public void 方法

public * Account.*()
Account中所有没有参数的public 方法

public * Account.*(..)
Account中所有的public 方法

* Account.*(..)
Account中的所有方法，包括private方法

!public * Account.*(..)
所有的非public 方法

   * Account+.*(..)
   所有的方法，包括子类的方法

   * java.io.Reader.read(..)
   所有的read方法

   * java.io.Reader.read(char[],..)
   所有以read(char[])开始的方法，包括read(char[])和read(char[],int,int)

   * javax..*.add*Listener(EventListener+)
   命名以add开始，以Listener结尾的方法，参数中为EventListener或子类

   * *.*(..) throws RemoteException
   抛出RemoteException的所有方法

   构造器，同上面
   public Account.new()
   没有参数的构造器方法

    属性签名模式
    同方法一样，属性也查不多
    * Account.*
    所有的Account属性

    !public static * banking..*.*
    所有的非public static 属性，在banking的包或者子包中

    3.主要的pointcuts类型

    分类pointcuts
    遵循特定的语法用于捕获每一个种类的可使用连接点。
    主要的种类：

方法执行：execution(MethodSignature)
方法调用：call(MethodSignature)
构造器执行：execution(ConstructorSignature)
构造器调用：call(ConstructorSignature)
类初始化：staticinitialization(TypeSignature)
属性读操作：get(FieldSignature)
属性写操作：set(FieldSignature)
例外处理执行：handler(TypeSignature)
对象初始化：initialization(ConstructorSignature)
对象预先初始化：preinitialization(ConstructorSignature)
Advice执行：adviceexecution()

   基于控制流的pointcuts
   主要包括两种类型的控制流：
   cflow(Pointcut)，捕获所有的连接点在指定的方法执行中，包括执行方法本身。
   cflowbelow(Pointcut)，捕获所有的连接点在指定的方法执行中，除了执行方法本身。

   如以下的例子：
   cflow(call(* Account.debit(..))
   所有的debit方法中的连接点，包括debit方法本身
   cflowbelow(call(* Account.debit(..))
   所有debit方法中的连接点，除了debit方法本身
   cflow(transactedOperations())
   所有由transactedOperations捕获的连接点
   cflowbelow(execution(Account.new(..))
   所有在Account 构造器中执行的连接点

   基于词汇结构的连接点
   源代码片断。，如within()和withincode()
   within ：捕获在指定类或者方面中的程序体中的所有连接点，包括内部类。
   Withincode：用于捕获在构造器或者方法中的所有连接点，包括在其中的本地类

   执行对象连接点
   匹配this,和target对象，作为方法被调用的对象。
   this(Account)，所有Account的实例的执行点，匹配所有的连接点，如方法调用，属性设置，当前的执行对象为Account，或者其子类。
   target(Account)：匹配所有的连接点，目标对象为Account或其子类。

   必须执行相应的类型，不能使用*,或者..通配符。当前静态方法，不能被匹配。

   在within()和this()中的区别：
   一个是程序体，而另一个为对象执行。

   参数pointcuts
   用于捕获参数类型的连接点。
   args(String,..,int)
   args(RemoteException)

   条件检测pointcuts
   if(System.currentTimeMillis()>triggerTime)

   基本的语法就这些，不过AspectJ5 已经增加了不少语法，主要关于Annotation 的，不过这部分还没有仔细研究，以后再讲解吧。希望能有所帮助

捕风 2006-10-19 17:28 发表评论