CDI现在使用JSR-330所定义的注解来声明注入点。这种影响是微乎其微的，因为330所使用的模型基本上与299大同小异。归结起来，只是注解名有所区别罢了。
要知道330并没有定义完整的依赖注入方案。它只定义了带有修饰符的注入点而已，其他的都没有定义。新的Managed Bean规范是JSR-299的工作成果（在规范的早期草案中我们称之为“简单Web Bean”）。简单Web Bean支持依赖注入、EL名字与拦截器，但却没有EJB那些编程约束。
Managed Bean规范引起了很多争议，Red Hat说我们确实需要支持普通Java类的注入，而其他EE涉众则表示对299定义这样一个新EE“组件”的行径感到非常不爽。
经过多次讨论后，我们认为这种“简单”组件的想法应该自成一个规范，以此构成所有其他EE组件编程模型的基础，包括EJB等等。这是一个非常棒的愿景，我们都很赞同这个观点，但EE 6并没有完全实现它。
最后的结果是：CDI可以用在普通的Java类（现在叫做“Managed Bean”）以及EJB上。现在的EJB可以看作是一种特殊的Managed Bean，只不过有一些额外的编程约束和功能。这种编程模型能够极大地降低新用户学习EE的曲线。我认为EE平台的未来发展方向是逐渐将EJB特有的功能通用化，将其应用在所有的Managed Bean上。举个例子，为何不是所有的Managed Bean都支持@TransactionAttribute和@RolesAllowed呢？简直没有道理嘛。
然而EJB在为消息传输定义端点、远程与异步方法调用、定时器等领域还是有一席之地的。在这些情况下，EJB生命周期模型还是非常有意义的。在尽力透明化用户体验的过程中，我们从来都没有真正满意过。用户总是注意到何时在使用JSF的特性，何时在使用本应放在JSF中的Seam特性。...我们相信大家都很渴望将这些技术用于Java
EE应用服务器之上，或是以插件的形式使用。通过增加更多的扩展点和服务供应商接口，其他技术就可以插件的形式用于平台实现了，这么做既整洁又高效，对于
开发者来说使用起来也是非常简单的，就像是内置于平台上的设备一样。可移植的扩展可以通过如下方式与容器集成：
• 提供自己的Bean、拦截器和装饰器。
• 通过依赖注入服务将依赖注入到自己的对象中。
• 为客户化的范围（custom scope）提供一个上下文实现。
• 通过外部注解增强或是提供基于注解的元数据。CDI和JSF 2的出现预示了Seam的新方向。
在Seam 2中，我们花费了巨大的精力填补JSF的漏洞，结果造成了没有时间集成那些非常吸引我们的表示层技术。JSF 2可以让我们将精力放在其他领域中。
最重要的是，CDI现在提供了一个核心“引擎”，可以在所有的EE
6应用服务器之间移植，甚至还可以用在Tomcat、Jetty和Resin上。该核心并不依赖于任何特定的表示层技术。其所拥有的仅仅是为可移植扩展开
发者所提供的一套定义良好的SPI。该SPI作为整个生态系统的根基。如果你是一位框架开发者，那现在就会明确要想将框架与CDI及EE环境集成起来（通
过扩展）需要做哪些事情。这也许是CDI最令人激动的特性了。
Seam 3将成为一套CDI可移植扩展，可以用在任何应用服务器上并向CDI编程模型提供扩展，同时能与我们感兴趣的其他技术进行集成。目前团队正与这些项目和平台（如ESB和SOA-P）紧密合作以确保新版Seam能考虑到其特定的需求。重要的是，一些项目已经认为Seam是其正确的选择，甚至都不用做任何修改，因此紧密与快速的集成要比想象的更容易一些。Red
Hat已经成功将Seam应用到其所开发的一些项目当中了。CDI将Seam的核心功能放在了坚固的根基之上，而我们对CDI的实现Weld是个更加专注
且测试良好的基础设施。这意味着我们可以将Weld应用在Seam 2不适合的各种领域中，而这与构建Web站点无关。我们认为JCDI非常适合于事件驱动架构的Flex RIA。JCDI应用非常整洁，尽管JBoss Seam提供了大量的特性，但他们没必要再开发一个RIA前端了。