源代码级的元数据通常是对类或方法这样的程序元素的属性或注解的补充。

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

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

我们也可以像下面这样为一个方法添加元数据：

/**
 * Normal comments here
 * @@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的语法。

源代码级的元数据随着XDoclet(在Java世界中)和Microsoft的.NET平台的发布被引入主流， 后者使用了源代码级的属性来控制事务、缓冲池(pooling)和一些其他的行为。

J2EE社区已经认识到了这种方法的价值。举例来说，跟EJB中专用的传统XML部署描述文件比起来它要简单很多。 与人们乐意做的把一些东西从程序源代码中提取出来的做法相反，一些重要的企业级设置 - 特别是事务特性 - 应该属于程序代码。 并不像EJB规范中设想的那样，调整一个方法的事务特性基本没有什么意义(尽管像事务超时这样的参数可能改变)。

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

下面有几种解决方案，包括：

为了与Spring提供的其他重要概念的抽象相一致，Spring为元数据实现提供了一个门面(facade)， 它是以org.springframework.metadata.Attributes接口的形式来实现。 这个门面因以下几个原因而显得很有价值：

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提供了比这更多的功能，比如定义在方法参数上的属性。

要注意到该接口像.NET一样提供了Object属性。这使得它区别于一些仅提供String属性的元数据属性系统， 比如Nanning Aspects。支持Object属性有一个显著的优点。它使属性能参与到类层次中， 还可以使属性能够灵活的根据它们的配置参数起作用。

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

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

Spring有很多自定义的Java 5+注解。

public class SimpleMovieLister {

    // the SimpleMovieLister has a dependency on the MovieFinder
    private MovieFinder movieFinder;

    // a setter method so that the Spring container can 'inject' a MovieFinder
    @Required
    public void setMovieFinder(MovieFinder movieFinder) {
        this.movieFinder = movieFinder;
    }
    
    // business logic that actually 'uses' the injected MovieFinder is omitted...
}

<bean id="movieLister" class="x.y.SimpleMovieLister">
    <!-- whoops, no MovieFinder is set (and this property is @Required) -->
</bean>

Exception in thread "main" java.lang.IllegalArgumentException:
    Property 'movieFinder' is required for bean 'movieLister'.

<bean class="org.springframework.beans.factory.annotation.RequiredAnnotationBeanPostProcessor"/>

<bean class="org.springframework.beans.factory.annotation.RequiredAnnotationBeanPostProcessor">
    <property name="requiredAnnotationType" value="your.company.package.Mandatory"/>
</bean>

package your.company.package;

import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface Mandatory {
}

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

Commons Attributes 2.2(http://jakarta.apache.org/commons/attributes/)是一个功能很强的元数据属性解决方案。 它支持通过构造方法参数和JavaBean属性来配置属性，这为属性定义提供了更好的自说明文档。 (对JavaBean属性的支持是在Spring小组的要求下添加的。)

我们已经看到了两个Commons Attributes的属性定义的例子。让我们大体上解释一下：

Bean的属性可以是这样的：

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

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

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

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

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

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

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

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

<target name="compileAttributes">

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

</target>

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

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

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

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

</attribute-indexer>

如果你的单元测试依赖于属性，尽量使它依赖于Spring Attributes抽象，而不是Commons Attributes。原因有两点， 其一是为了更好的移植性 - 举例来说，你的测试用例将来仍可以工作如果你转换至Java 1.5的属性 - 它简化了测试。 其次，Commons Attributes是静态的API，而Spring提供的是一个容易模拟的元数据接口。

元数据属性最有用的就是与Spring AOP联合使用。这提供了一个类似.NET的编程模型：声明式服务会自动提供给声明了元数据的属性。 这些元数据属性可以被框架支持，比如声明式事务管理，同时也能定制。

<bean class="org.springframework.aop.framework.autoproxy.DefaultAdvisorAutoProxyCreator"/>

<bean class="org.springframework.transaction.interceptor.TransactionAttributeSourceAdvisor">
  <property name="transactionInterceptor" ref="txInterceptor" />
</bean>

<bean id="txInterceptor" class="org.springframework.transaction.interceptor.TransactionInterceptor">
  <property name="transactionManager" ref="transactionManager" />
  <property name="transactionAttributeSource">
    <bean class="org.springframework.transaction.interceptor.AttributesTransactionAttributeSource">
      <property name="attributes" ref="attributes" />
    </bean>
  </property>
</bean>

<bean id="attributes" class="org.springframework.metadata.commons.CommonsAttributes" />