Spring Framework 开发参考手册 之八 源代码级的元数据支持

原创 2005年04月28日 15:30:00

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

8.1. 源代码级的元数据

源代码级的元数据是对程序元素:通常为类和/或方法的 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类。

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

  • JSR-175:标准的Java元数据实现,在Java 1.5中提供。 但是我们现在就需要一个解决方案,通常情况下可能还需要一个外观(facade)。

  • XDoclet:成熟的解决方案,主要用于代码生成

  • 其它不同的开源attribute实现,在JSR-175的发布 悬而未决的情况下,它们当中的Commons Attributes看来是最有前途的。所有的这些实现都需要一 个特定的前编译或后编译的步骤。

8.2. Spring的元数据支持

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

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

  • 目前还没有一个标准的元数据解决方案。 Java 1.5版本会提供一个,但是在Spring1.0版本的时候, Java 1.5仍是beta版本。而且,至少两年内还是需要对1.3和1.4版本的应用程序提供元数据支持。 现在Spring打算提供一些可以工作的解决方案: 在一个重要的环境下等待1.5,并不是个好的选择.

  • 目前的元数据API,例如Commons Attributes(被Spring 1.0使用), 测试起来很困难。Spring提供了一个简单的更容易模拟的元数据接口。

  • 即使当Java 1.5在语言级别提供了对元数据的支持时,提供了一个如此的抽象仍然是有价值的:

    • JSR-175的元数据是静态的。它是在编译时与某一个类关联,而在部署环境下是不可改变的。 这里会需要多层次的元数据,以支持在部署时重载某些attribute的值--举例来说, 在一个XML文件中定义用于覆盖的attribute。

    • JSR-175的元数据是通过Java反射API返回的。这使得在测试时无法模拟元数据。 Spring提供了一个简单的接口来允许这种模拟。

虽然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的实现变得容易起来。

8.3. 集成Jakarta Commons Attributes

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

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

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

  • Attribute类的名称。 这可能是一个FQN,就像上面的那样。如果相关的attribute类已经被导入, 就不需要FQN了。你也可以在attibute编译器的设置中指定attribute的包名。

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

Bean的属性如下:

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

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

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

为了在整个构建过程中运行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.接下来,定义一个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提供的是一个容易模拟的元数据接口。

8.4. 元数据和Spring AOP自动代理

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

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

8.4.1. 基础

基于Spring AOP自动代理功能实现。配置可能象这样:

<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"
/>

这里的基本概念和AOP章节中关于自动代理的讨论一致。

最重要的bean的定义名称为autoproxytransactionAdvisor。要注意bean的实际名称并不重要; 关键是它们的类。

所定义的自动代理bean org.springframework.aop.framework.autoproxy.DefaultAdvisorAutoProxyCreator 将自动通知(“自动代理”)当前工厂类中的所有符合Advisor实现的bean实例, 这个类并不知道attribute,而是依赖符合的Advisors的切入点。这些切入点知道attribute的内容。

因而我们只是需要一个AOP的advisor来提供基于attribute的声明式事务管理。

也可以添加任意的自定义Advisor实现,它们将被自动计算并应用。 (如果有必要的话,你可以使用切入点除了符合自动代理配置的attribute,而且满足一定规则的Advisor。)

最后,attributes bean使用的是Commons Attributes的实现。 也可以用org.springframework.metadata.Attributes的另一个实现代替。

8.4.2. 声明式事务管理

源代码级的attribute的最普通用法是提供了类似.NET的声明式事务管理。一旦定义好上面的bean定义, 你就能定义任意数目的需要声明式事务的应用对象了。只有那些拥有事务attribute的类或方法会被有事务的通知。 除了定义你需要的事务attribute以外,其他什么都不用做。

不象在.NET中那样,你可以在类或方法级别指定事务attribute。 如果指定了类级别的attribute,它的所有方法都会“继承”它。 方法中定义的attribute将完全覆盖类上定义的attribute。

8.4.3. 缓冲池技术

再者,象.NET中一样,你可以通过在类上指定attribute增加缓冲池行为。 Spring能把该行为应用到任何普通Java对象上。你只需在需要缓冲的业务对象上指定一个缓冲池的attribute,如下:

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

你需要通常的自动代理的基本配置。 然后指定一个支持缓冲池的TargetSourceCreator,如下所示。 由于缓冲池会影响目标对象的创建,我们不能使用一个通常的advice。 注意如果一个类有缓冲池的attribute,即使没有任何advisors应用到该类,缓冲池也会对该类起作用。

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

对应的自动代理bean定义需要指定一系列的“自定义的目标源生成器”,包括支持缓冲池的目标源生成者。 我们可以修改上面的例子来引入这个属性,如下:

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

就像通常在Spring中使用元数据一样,这是一次性的耗费:一旦创建完成后, 在其它业务对象上使用缓冲池是非常容易的。

对于很少需要缓冲池技术的地方,很少需要缓冲大量业务对象,这是就值得斟酌了。 因此这个功能好像也不是经常使用。

详细请参考org.springframework.aop.framework.autoproxy包的Javadoc。 除了以最少的代码量使用Commons Pool以外,其它的缓冲池实现也是可以的。

8.4.4. 自定义的元数据

由于自动代理底层架构的灵活性,我们甚至还可以超越.NET元数据attribute的功能。

我们可以定义一些自定义的attribute来提供任何种类的行为。为了达到这个目的,你需要:

  • 定义你的自定义attribute类

  • 定义一个Spring AOP Advisor,自定义attributes的出现的时候触发它的切入点。

  • 把Advisor当作一个bean的定义添加到一个包含普通自动代理基础架构的应用上下文中。

  • 把attribute添加到普通Java对象上。

有几个潜在的领域中你可能想这么做,比如自定义的声明式安全管理,或者可能的缓存。

这是一个功能很强的机制,它能显著减少某些工程中的配置工作。但是,要记住它在底层是依赖AOP的。 你在应用的使用的Advisors越多,运行时配置将会越复杂。(如果你想查看object上应用了哪些通知, 可以看一下关于org.springframework.aop.framework.Advised的参考。它使你能够检查相关的Advisors。)

8.5. 使用attribute尽可能减少MVC web层配置

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

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

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

  • Controller实例是显式的被Spring IoC通过XML bean定义来管理。

  • 该映射位于controller的外面, 所以相同controller的实例可以在同一个DispatcherServlet中被赋予不同的映射或者在不同的配置中重用。

  • Spring MVC能够支持在任何规则上的映射,而不是大多数其它框架中仅有的将请求URL映射到控制器。

然而,对于每个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");
    }

}

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

  • 显著的减少配置工作量。每一次我们增加一个控制器时,我们需要XML的配置。 就像attribute驱动的事务管理一样,一旦有了基础架构后,添加更多的应用类将会很简单。

  • 我们保留了Spring IoC配置控制器的能力。

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

  • 这个方法使构建过程更加复杂,不过开销是一次性的。 我们需要一个attribute编译步骤和一个建立attribute的索引步骤。 但是,一旦这些步骤就位后,这将不再是一个问题。

  • 虽然将来会增加对其他attribute提供者的支持,但目前只支持Commons Attributes。

  • 只有“根据类型的自动装配”的依赖注射才支持这样的控制器。但是, 这妨碍这些控制器对Structs Actions(在框架中并没有IoC的支持), 和值得斟酌的WebWork Actions(只有基本的IoC支持,并且IoC逐步受到关注)的领先。

  • 依赖自动魔法的IoC解决方案可能是令人困惑的。

由于根据类型的自动装配意味着必须依赖一种指定类型,如果我们使用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实现的支持,并且必须支持索引, 你可以简单的继承AbstractPathMapHandlerMappingCommonsPathMapHandlerMapping的父类, 用你选择的attribute API来实现其中两个protected的虚方法。)

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

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

8.6. 元数据attribute的其它使用

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

8.7. 增加对其它的元数据API的支持

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

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

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

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

Spring Framework 开发参考手册中文(在线HTML)

‘原文:http://blog.csdn.net/zfrong/article/details/3971722 Spring Framework 开发参考手册中文(在线HTML)        ...

Velocity和FreeMarker - Spring Framework reference 2.0.5 参考手册中文版

Velocity 和 FreeMarker 是两种模板语言,都可以做为view层技术在Spring MVC 应用中使用。它们的语言风格和适用对象都很相似,这里把它们放在一起讨论。至于它们语义和语法上的...

Spring Framework 开发参考手册

  • 2009年01月15日 21:38
  • 2.08MB
  • 下载

Spring - Java/J2EE Application Framework 应用框架 第 8 章 源代码级的元数据支持

第 8 章 源代码级的元数据支持 8.1. 源代码级的元数据 源代码级的元数据是对程序元素:通常为类和/或方法的 attribute 或者叫annotation...

Spring Framework 开发参考手册

  • 2008年12月19日 12:00
  • 2.09MB
  • 下载

Spring Framework 开发参考手册

  • 2008年12月16日 21:08
  • 2.6MB
  • 下载

Spring Framework 开发参考手册 - Spring Framework reference 2.0.5 参考手册中文版

原文:http://doc.javanb.com/spring-framework-reference-zh-2-0-5/ Spring Framework 开发参考手册 - Spr...

Spring Framework2.0 中文开发参考手册

  • 2007年08月14日 17:50
  • 2.14MB
  • 下载
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:Spring Framework 开发参考手册 之八 源代码级的元数据支持
举报原因:
原因补充:

(最多只允许输入30个字)