源代码级的元数据是对程序元素:通常为类和/或方法的 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类可能会失败。在这种情况下,你可以看看所生成的类来确定错误的原因。

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

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

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

</attribute-indexer>

如果你的单元测试依赖于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的更简单的方法，对于一些简单场景来说是一个吸引人的选择。

在这种方法下，控制器上标记了一个或多个类级的元数据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文件来建立索引。

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

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

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

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