26.4.集成Jakarta Commons Attributes

优质
小牛编辑
126浏览
2023-12-01

26.4. 集成Jakarta Commons Attributes

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

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

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

  • 属性类的名称。这可能是一个完整的名字(fully qualified name, FQN),就像上面的那样。如果相关的属性类已经被导入,就不需要FQN了。你也可以在属性编译器的设置中指定属性的包名。

  • 任何必须的参数化。可以通过构造方法参数或者JavaBean属性完成。

Bean的属性如下:

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

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

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

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

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

  • Commons Attributes编译器的jar包和API的jar包。

  • 来自于XDoclet的xjavadoc.jar

  • 来自于Jakarta Commons的commons-collections.jar

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

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

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

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

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

</attribute-indexer>

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

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