Tapestry IoC容器从历史上来说，是从从HiveMind继承发展而来，但是HiveMind和目前大红大紫的Spring都不能满足Tapestry的一些特定的需求，所以全新开发了一套IoC的容器。
其核心思想就是使用Java代码自身来解决依赖注入而不是由Xml之类的配置文件来完成，这和Guice的思想是非常相似的，Lewis也承认从Guice那里借鉴了不少。
另外需要说明一下的是，Tapesty还从中国的一个非常古老但又充满哲理的游戏--围棋中借鉴了一些术语和思想。大意是围棋中经常要把棋子走的轻盈(Lightness)，让每个棋子都能尽量地高效。编程也一样要轻量(Lightness)。
IoC容器中使用的一些概念，充分理解这些概念会对Tapesty IoC容器有一个总体上的感性认识。
Tapestry IoC中的最基本的组成单元是服务(Service)。服务一般由一个接口和一个接口的实现组成。每个服务都有一个全局唯一的标识(ID)。
数个或者多个服务组成一个模块。模块中会包括一个模块定义类，在这个类里面有一系列的静态或者成员方法
，用于定义服务、装饰服务、或者添加配置项。
这个类中的方法定义服务，并同时负责实例化服务的实现类。
这些方法被称为：服务创建 (build) 方法。
注册表(Registry) 是外部世界与服务和模块交互的媒介。通过注册表，使用服务的ID或者服务接口，才有可能获得一个服务（服务ID是大小写不敏感的，这是Tapestry的一个随处可见的特性）。
服务可以由服务装饰方法进行装饰(decorate)。这些装饰方法会创建拦截器(interceptor)来包装核心的服务实现，
在外面添加诸如日志、权限检查、数据库事务之类的行为。拦截器需要实现同样服务接口，这实际上就是一个装饰模式的应用。
下面是关于服务的一个很重要的概念：配置(Configuration)。
在Tapestry的AppModule.java中最常见的是两类方法，一类是前面刚刚介绍过的服务创建方法，一般是以build开头的。另一大类就是添加配置的方法了，一般是以contribute开头。
服务可以根据配置项灵活配置，配置的数据结构可以是Map、集合或者是有序列表。
服务自己定义允许什么类型的配置项可以被添加到配置中，Tapestry中把添加配置项的动作称之为贡献(Contribute)。
配置可以由一个或者多个模块分别贡献而成。通过调用服务贡献方法(Service Contributor Methods)来把配置对象添加到配置中。
服务的状态演变：
服务只有在需要的时候才会被实例化。在这里，“需要”的意思是服务的某个方法被调用了。开始的时候，从外界来看，服务只是一个实现了服务接口的代理。
当这个代理的方法第一次被实际调用的时候，完整的服务（也就是服务的实现类）才会真正地被构造。
并且这个构造过程是线程安全的。
实例化服务、进行依赖注入、装饰服务这就是服务实现(Realization)的所有组成部分。通过这三步一个服务才从虚拟状态(只是一个代理)转换成真实状态(完全的实例化，等待被使用了)。
服务的范围：服务的缺省范围是单例的，另外也可以与当前线程绑定.
依赖项是服务实现类所需要的其他服务。依赖项可以由服务创建方法通过构造函数、方法参数注入进来。
注入点可以是类成员属性、方法参数、或者构造函数参数。通常使用注解来指定注入的类型。
这篇文章是拷贝过来的，没有发现转载。。。
buildXxx()方法中的参数一直是我迷茫的地方，后来听一个大牛说，就是TapestryIoc中的各种服务都可以作为参数。。。