第 8 章 源代码级的元数据支持

源代码级的元数据是对程序元素:通常为类和/或方法的 attribute 或者叫annotation的扩充。

举例来说，我们可以象下面一样给一个类添加元数据：

/*** Normal comments* @@org.springframework.transaction.interceptor.DefaultTransactionAttribute()*/
public class PetStoreImpl implements PetStoreFacade, OrderService {

我们也可以添加元数据到一个方法上：

/*** Normal comments* @@org.springframework.transaction.interceptor.RuleBasedTransactionAttribute ()* @@org.springframework.transaction.interceptor.RollbackRuleAttribute (Exception.class)* @@org.springframework.transaction.interceptor.NoRollbackRuleAttribute ("ServletException")*/
public void echoException(Exception ex) throws Exception {....
}

这两个例子都使用了Jakarta Commons Attributes的格式。

源代码级的元数据随着Microsoft的.NET平台的发布被介绍给大众，它使用了源代码级的attribute 来控制事务,缓冲池(pooling)和一些其他的行为。

这种方法的价值已经被J2EE社区的人们认识到了。举例来说，跟EJB中清一色使用的传统的XML部署描述文 件比起来它要简单很多。XML描述文件适合于把一些东西从程序源代码中提取出来,一些重要的企业级设 定——特别是事务特性——本来属于程序代码。并不像EJB规范中设想的那样，调整一个方法的事务特性根本 没有什么意义。

虽然元数据attribute主要用于框架的基础架构来描述应用程序的类需要的业务， 但是也可以在运行时查询元数据attribute。这是与XDoclet这样的解决方案的关键区别，XDoclet 主要把元数据作为生成代码的一种方式，比如生成EJB类。

这一段包括了几个解决方案:

为了与它提供的其他重要概念的抽象相一致，Spring提供了一个对元数据实现的外观（facade）， 以org.springframework.metadata.Attributes这个接口的形式来表示。

这样一个外观很有价值，因为下面几个原因：

虽然Spring在Java 1.5达到它的GA版本之前将支持JSR-175，但仍会继续提供一个attribute抽象API。

Spring的Attributes接口看起来是这样的：

public interface Attributes {Collection getAttributes(Class targetClass);Collection getAttributes(Class targetClass, Class filter);Collection getAttributes(Method targetMethod);Collection getAttributes(Method targetMethod, Class filter);Collection getAttributes(Field targetField);Collection getAttributes(Field targetField, Class filter);
}

这是个最普通不过的命名者接口。JSR-175能提供更多的功能，比如定义在方法参数上的attributes。 在1.0版本时，Spring目的在于提供元数据的一个子集，使得能象EJB或.NET一样提供有效的声明式企业级服务。 1.0版本以后，Spring将提供更多的元数据方法。

注意到该接口像.NET一样提供了Object类型的attibute。 这使得它区别于一些仅提供String类的attribute的attribute系统， 比如Nanning Aspects和JBoss 4（在DR2版本时）。支持Object类型的attribute有一个显著的优点。 它使attribute含有类层次，还可以使attribute能够灵活的根据它们的配置参数起作用。

对于大多数attribute提供者来说，attribute类的配置是通过构造函数参数或JavaBean的属性完成的。Commons Attributes同时支持这两种方式。

同所有的Spring抽象API一样，Attributes是一个接口。 这使得在单元测试中模拟attribute的实现变得容易起来。

虽然为其他元数据提供者来说，提供org.springframework.metadata.Attributes 接口的实现很简单，但是目前Spring只是直接支持Jakarta Commons Attributes。

Commons Attributes 2.0 （http://jakarta.apache.org/commons/sandbox/attributes/） 是一个功能很强的attribute解决方案。它支持通过构造函数参数和JavaBean属性来配置attribute, 也提供了更好的attribute定义的文档。（对JavaBean属性的支持是在Spring team的要求下添加的。）

我们已经看到了两个Commons Attributes的attribute定义的例子。通常，我们需要解释一下:

Bean的属性如下：

/*** @@MyAttribute(myBooleanJavaBeanProperty=true)*/

把构造函数参数和JavaBean属性结合在一起也是可以的(就像在Spring IoC中一样)。

因为，并不象Java 1.5中的attribute一样，Common Attributes没有和Java语言本身结合起来， 因此需要运行一个特定的attribute编译的步骤作为整个构建过程的一部分。

为了在整个构建过程中运行Commmons Attributes，你需要做以下的事情。

1.复制一些必要的jar包到$ANT_HOME/lib目录下。 有四个必须的jar包，它们包含在Spring的发行包里：

2.把Commons Attributes的ant任务导入到你的项目构建脚本中去，如下：

<taskdef resource="org/apache/commons/attributes/anttasks.properties"/>

3.接下来，定义一个attribute编译任务，它将使用Commons Attributes的attribute-compiler任务 来“编译”源代码中的attribute。这个过程将生成额外的代码至destdir属性指定的位置。 在这里我们使用了一个临时目录：

<target name="compileAttributes" ><attribute-compiler destdir="${commons.attributes.tempdir}" ><fileset dir="${src.dir}" includes="**/*.java"/></attribute-compiler></target>

运行javac命令编译源代码的编译目标任务应该依赖于attribute编译任务，还需要编译attribute时生成至 目标临时目录的源代码。如果在attribute定义中有语法错误，通常都会被attribute编译器捕获到。 但是，如果attribute定义在语法上似是而非,却使用了一些非法的类型或类名, 编译所生成的attribute类可能会失败。在这种情况下,你可以看看所生成的类来确定错误的原因。

Commons Attributes也提供对Maven的支持。请参考Commons Attributes的文档得到进一步的信息。

虽然attribute编译的过程可能看起来复杂,实际上是一次性的耗费。一旦被创建后,attribute的编译是递增式的， 所以通常它不会减慢整个构建过程。一旦编译过程完成后， 你可能会发现本章中描述的attribute的使用将节省在其他方面的时间。

如果需要attribute的索引支持（目前只在Spring的以attribute为目标的web控制器中需要，下面会讨论到）， 你需要一个额外的步骤，执行在包含编译后的类的jar文件上。在这步可选的步骤中， Commons Attributes将生成一个所有在你源代码中定义的attribute的索引，以便在运行时进行有效的查找。 该步骤如下：

<attribute-indexer jarFile="myCompiledSources.jar"><classpath refid="master-classpath"/></attribute-indexer>

可以到Spring jPetStore例程下的attributes目录下察看关于该构建过程的例子。 你可以使用它里面的构建脚本，并修改该脚本以适应你自己的项目。

如果你的单元测试依赖于attribute,尽量使它依赖于Spring对于Attribute的抽象,而不是Commons Attributes。 这不仅仅为了更好的移植性——举例来说，你的测试用例将来仍可以工作如果你转换至Java 1.5的attributes—— 它也简化了测试。Commons Attributes是静态的API，而Spring提供的是一个容易模拟的元数据接口。

元数据attributes最重要的用处是和Spring AOP的联合。 提供类似于.NET风格的编程模式，声明式的服务会被自动提供给声明了元数据attribute的应用对象。 这样的元数据attribute可以像在声明式事务管理一样被框架直接支持，也可以是自定义的.

这就是AOP和元数据attribute配合使用的优势所在。

<bean id="autoproxy" class="org.springframework.aop.framework.autoproxy.DefaultAdvisorAutoProxyCreator">
</bean><bean id="transactionAttributeSource"class="org.springframework.transaction.interceptor.AttributesTransactionAttributeSource"autowire="constructor">
</bean><bean id="transactionInterceptor"class="org.springframework.transaction.interceptor.TransactionInterceptor"autowire="byType">
</bean><bean id="transactionAdvisor"class="org.springframework.transaction.interceptor.TransactionAttributeSourceAdvisor"autowire="constructor" >
</bean><bean id="attributes"class="org.springframework.metadata.commons.CommonsAttributes"
/>

 /** * @@org.springframework.aop.framework.autoproxy.target.PoolingAttribute (10)* * @author Rod Johnson*/
public class MyClass {

<bean id="poolingTargetSourceCreator"class="org.springframework.aop.framework.autoproxy.metadata.AttributesPoolingTargetSourceCreator"autowire="constructor" >
</bean>

<bean id="autoproxy" class="org.springframework.aop.framework.autoproxy.DefaultAdvisorAutoProxyCreator">
><property name="customTargetSourceCreators"><list><ref local="poolingTargetSourceCreator" /></list></property>
</bean>

Spring 1.0中的元数据的另一个主要用法是为简化Spring MVC web配置提供了一个选择。

Spring MVC提供了灵活的处理器映射： 将外来的请求映射到控制器（或其它的处理器)实例上。 通常上处理器映射被配置在相应的Spring DispatcherServlet的xxx-servlet.xml文件中。

把这些配置定义在DispatcherServlet的配置文件中通常是个不错的选择。它提供了最大的灵活性。 特别的是：

然而，对于每个controller来说，我们同时需要一个处理器映射（通常是一个处理器映射的XML bean定义）， 和一个控制器自身的一个XML映射描述。

Spring提供了一个基于源代码级attribute的更简单的方法，对于一些简单场景来说是一个吸引人的选择。

这一段描述的方法很适合一些简单的MVC场景。但它牺牲了一些Spring MVC的功能， 比如根据不同的映射使用相同的控制器，把映射基于除了请求的URL之外的规则。

在这种方法下，控制器上标记了一个或多个类级的元数据attribute， 每一个attribute指定了它们应该映射的一个URL。

下面的例子展示了这种方法。在每一种情况下，我们都有一个依赖于Cruncher类的业务对象控制器。 和往常一样，这种依赖性将通过依赖注射来解决。 Cruncher必须作为一个bean定义出现在相关的DispatcherServlet的XML文件中，或在一个父上下文中。

我们把一个attribute设置到控制器类上，并指定应该映射的URL。 我们可以通过JavaBean属性或构造函数参数来表达依赖关系。这种映射必须通过自动装配来解决： 那就是说，在上下文中必须只能有一个Crucher类型的业务对象。

/*** Normal comments here* @author Rod Johnson* @@org.springframework.web.servlet.handler.metadata.PathMap("/bar.cgi")*/
public class BarController extends AbstractController {private Cruncher cruncher;public void setCruncher(Cruncher cruncher) {this.cruncher = cruncher;}protected ModelAndView handleRequestInternal(HttpServletRequest arg0, HttpServletResponse arg1) throws Exception {System.out.println("Bar Crunching c and d =" + cruncher.concatenate("c", "d"));return new ModelAndView("test");}}

为了使这个自动映射起作用，我们需要添加下面的配置到相关的xxxx-servlet.xml文件中， 这些配置是用来指定相关attribute的处理器映射的。 这个特殊的处理器映射可以处理任意数量的象上面一样带有attribute的控制器。 Bean的id（“commonsAttributesHandlerMapping”）并不重要。关键是它的类型：

<bean id="commonsAttributesHandlerMapping"      class="org.springframework.web.servlet.handler.metadata.CommonsPathMapHandlerMapping"
/>

现在我们并不需要一个象上面例子中的Attributes bean的定义， 因为这个类直接利用Commons Attributes API，而不是通过Spring的元数据抽象。

现在我们不再需要对每一个控制器提供XML配置。控制器被自动映射到指定的URL上。 控制器得益于IoC，使用了Spring的自动装配功能。举例来说， 上述的简单控制器中的“cruncher”属性上的依赖性会自动在当前的web应用中解决． Setter方法和构造函数依赖注射都是可以的，每一个都是零配置。

构造函数注册的一个例子，同时演示了多个URL路径：

/**
* Normal comments here
* @author Rod Johnson
*
* @@org.springframework.web.servlet.handler.metadata.PathMap("/foo.cgi")
* @@org.springframework.web.servlet.handler.metadata.PathMap("/baz.cgi")
*/
public class FooController extends AbstractController {private Cruncher cruncher;public FooController(Cruncher cruncher) {this.cruncher = cruncher;}protected ModelAndView handleRequestInternal(HttpServletRequest arg0, HttpServletResponse arg1) throws Exception {return new ModelAndView("test");}}

这种方法有着下列的好处：

不过该方法有如下的限制：

由于根据类型的自动装配意味着必须依赖一种指定类型，如果我们使用AOP就需要小心了。 在通常使用TransactionProxyFactoryBean的情况下，举例来说， 我们对一个业务接口例如Cruncher有两个实现： 一个为原始的普通Java对象的定义，另一个是带有事务的AOP代理。这将无法工作， 因为所有者应用上下文无法确切的解析这种类型依赖。解决方法是使用AOP的自动代理， 建立起自动代理的基本架构，这样就只有一个Crucher的实现， 同时该实现是自动被通知的。 因此这种方法和上面的以attribute为目标声明式服务能很好的一起工作。 因为attribute编译过程必须恰当处理web控制器的定位，所有这就很容易被创建

不象其它的元数据的功能，当前只有Commons Attributes的一种实现： org.springframework.web.servlet.handler.metadata.CommonsPathMapHandlerMapping。 这个限制是因为我们不仅需要attribute编译，还需要attribute索引： 根据attribute API来查询所有拥有PathMap attribute的类。虽然将来可能会提供， 但目前在org.springframework.metadata.Attributes的抽象接口上还没有提供索引。 （如果你需要增加另一个attribute实现的支持，并且必须支持索引， 你可以简单的继承AbstractPathMapHandlerMapping，CommonsPathMapHandlerMapping的父类， 用你选择的attribute API来实现其中两个protected的虚方法。）

因此我们在构建过程中需要两个额外的步骤：attribute编译和建立attribute索引。 上面已经展示了attributer索引建立器的使用方法。要注意到目前Commons Attributes仍需要一个Jar文件来建立索引。

如果你开始使用控制器元数据映射方法，你可以在任何一个地方转换至经典的Spring XML映射方法。 所以你不需要拒绝这种选择。正因为这个原因，我发现我经常在开始一个web应用时使用元数据映射．

对元数据attribute的其它应用看来正在流行。到2004年3月时， 一个为Spring建立的基于attribute的验证包正在开发中。 当考虑到潜在的多次使用时，attribute解析的一次性开销看起来更加吸引人了．

如果你希望提供对另一种元数据API的支持，这是容易做到的。

简单的实现org.springframework.metadata.Attributes 接口作为你选择的元数据API的 外观（facade）。然后你就可以象上面那样把这个对象包括到你的bean定义中去。

所有使用元数据的框架服务，例如AOP元数据驱动的自动代理，将自动使用你的新元数据提供者。

我们期待着增加对Java 1.5的attribute的支持－－可能作为Spring核心的附件－－在2004年第二季度。