CDI feature

CDI
Java EE的上下文和依赖注入（Contexts and Dependency Injection for Java EE，CDI），CDI是即将完成的Java EE 6平台的关键组成部分，经由JSR 299进行标准化。CDI是Java EE整个下一代类型安全的依赖注入的事实上的API。JSR 299由Gavin King领导，其目标是综合来自诸如Seam、Guice和Spring一类的解决方案的最好的依赖注入功能，同时加入许多自己的有用创新。

上下文
要完全了解什么是上下文，我们首先需要明白web应用是怎样运行的。现代计算机应用是可对话性质的，用户发送请求开始启动应用，传入一些预定的数据单元，直到最后一个预先定义的工作完成，请求会接收到反馈输出。这一过程中在计算机和终端用户之间存在着一些来回往复，计算机应用程序与用户必须进行多次交互，积累和处理数据直到它可以构造出所期望的输出。应用程序必须维护当前用户的数据状态，直到应用程序终止，这种类型的应用被认为是“有状态的”。Web应用程序使基于HTTP写的，HTTP其本身是无状态的，它是一种请求/响应协议，其中事务的状态只有在一个请求的处理过程中是活跃的。JEE服务器通过提供数据结构保存有状态的数据来确保应用的“有状态性”。当web应用程序使用Servlet规范，应用程序生命周期是可实现的，在生命周期的不同部分，有一些明确定义的数据的范围，我们称之为上下文，具体包括：

Application - 应用程序上下文，即数据在应用程序上下文中可用。换句话，数据在应用程序部署到应用程序卸载或删除这段时间可用。这是最高级别的上下文。
Session - 会话上下文，即数据存储在会话中，数据只有在会话被某一用户创建到会话被移除这段时间内被这个用户可用。
Request - 请求上下文，数据只有在同一个用户的同一个请求中可用，当请求返回，数据不再被服务器维护。

依赖注入

依赖注入，即是由CDI定义的依赖注入，对象可以以类型安全的方式插入到其他应用程序对象中的过程。可以将注入对象的特定实现的决定延迟到应用程序部署时。在其他框架中，注入是基于字符串匹配的。CDI通过在编译时检查类型的类型的类型注入来改进这一点。这将在开发生命周期的早期暴露注入错误，并使调试更加容易。

依赖注入的一个最大的好处是应用组件之间的松耦合。客户机和服务器组件是松散耦合的，因为可以将服务器的几个不同版本注入到客户机中。客户机使用一个接口，并且不知道它正在与哪个服务器通信。利用部署时注入，我们可以为不同类型的环境（如生产和测试环境）使用特定的对象。例如，我们可以根据部署环境注入生产或测试数据源

其他CDI的特性

除了上下文和依赖注入外，CDI还提供了一些其他特性：

EL表达式的扩展：CDI中默认支持EL表达式并对其进行了扩展，比如在JSF或JSP中，默认是不支持EL表达式传参的，如果结合CDI，那么就可以在EL表达式中传参数给后台Bean。
拦截器：CDI提供了一个十分方便的方法来实现一个或多个拦截器，用来处理 cross-cutting concerns such as logging

装饰器：装饰器可以让你动态的扩展或者重写现有的业务接口。这个功能十分方便，在CDI中，你在调用一个接口的实现类的时候，无须关心这个实现类的名称，所以在你更换新的实现的时候无需去修改你的代码，只需要在新的接口上面通过装饰器声明你要替换的之前的接口实现，然后在 bean.xml 中声明一下即可。

事件：CDI 提供了一种松耦合性的事件发送和接受机制。比如，在用户登陆后，我们需要在Session中存放一些用户信息。有了这个机制，我们不需要在登陆的那个方法中 通过new一个Session范围的对象或者把一些数据放入Session中，这样修改这些方法的时候，我们就得去修改这个登陆方法的。或者说 我们突然需要在用户登陆后，额外做一些事情，我们又得去修改登陆这块的代码。 在CDI中，我们可以在登陆成功后，发送出一个登陆成功的事件，然后我们可以在任何类中来接受这个事件，来完成对应的工作。

类型安全：CDI不在通过字符串名称来注入对象，而通过java类型来确定被注入的对象。当只是通过java类型还不能确定到底哪一个对象被注入的时候，你可以通过扩展 @Qualifier 注解来限定你需要注入的对象。

注解：CDI中所有的注入都是通过注解来完成的，XML相关的配置非常少

普通的Java Bean ：在CDI中基本上所有的 Java Bean 都可以被注入。当然包括：EJB、JNDI资源、持久化单元、持久化上下文、接口等等。